source ip interface/address
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().
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.
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:
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 We can rework this change based on PR #78, but is PR #78 going to be merged?
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).