pam_tacplus icon indicating copy to clipboard operation
pam_tacplus copied to clipboard

source ip interface/address

Open stanAtAtl opened this issue 9 years ago • 5 comments

This patch adds code in _pam_parse() to parse new option "source_ip" and stores the converted address information in static memory. The address info is then used when calling tac_connect_single().

stanAtAtl avatar Dec 08 '16 20:12 stanAtAtl

In general, I'm opposed to this change.

We're seeing an increase of session parameters (not a bad thing) but they're being added as globals (which is a bad thing).

Please look at PR #78 and consider making this a session parameter instead.

pprindeville avatar Dec 13 '16 06:12 pprindeville

Having had a look at PR #78, it may not be a very bad idea to make srcaddr a member of struct tac_session, but I failed to see any real benefit from doing so. My understanding is that the srcaddr is used only in and by tac_connect_single() and it is already there but not used (NULL was passed in always). There is no much similarity to putting fd to the session.

stanAtAtl avatar Dec 15 '16 21:12 stanAtAtl

@stanAtAtl:

Having had a look at PR #78, it may not be a very bad idea to make srcaddr a member of struct tac_session, but I failed to see any real benefit from doing so. My understanding is that the srcaddr is used only in and by tac_connect_single() and it is already there but not used (NULL was passed in always).

A sockaddr is 16 bytes. A sockaddr_in6 is 28 bytes long. A sockaddr_in is 16 also, but only 8 bytes are used (the rest are padding to blow it out to the same length as a sockaddr). It's not an excessive trade-off for a cleaner API versus 28 bytes more of overhead per structure.

What do you mean "NULL was passed in always"?

It's passed in as NULL by tacc.c and pam_tacplus.c, but there are other programs out there which use it (I know because mine is one of them).

pprindeville avatar Dec 15 '16 22:12 pprindeville

@pprindeville We can rework this change based on PR #78, but is PR #78 going to be merged?

mbennett2212 avatar Jun 20 '17 21:06 mbennett2212

We can rework this change based on PR #78, but is PR #78 going to be merged?

@mattbennett2 I'm trying to find the time to kick out a final release of 1.5.0 (or whatever) and then start a separate fork of 2.0 since this will be fairly disruptive (and definitely not ABI compatible).

pprindeville avatar Jun 20 '17 22:06 pprindeville