Add VSA shell:priv-lvl support for privileged radius user logins

Ticket: CM-19457
Reviewed By: roopa
Testing Done: lots of variations of login, su, sudo, automated radius tests

Now we always read the map files.  If session is set, we try that
file first, so that a user always sees their name, same as tacplus.
If that's the wrong file, read through all of the map files, look
for the correct match based on either name+session or auid+session,
depending on getpwnam or getpwuid entry point

Ignore same set of users as tacacs, including new radius_priv_user
account for the privileged RADIUS user.

create and delete the mapuser files from libpam-radius-auth now;
we need to have the mapping file written early enough for the pam
interfaces to get the correct info.

Using the pam_script is too limiting, and since we are creating the
database in libpam-radius-auth now, we'll delete it there as well
to keep things symmetric, so delete the script and the references to
the scripts

A significant part of this effort was adding getgrent, getgrgid, and
getgrnam support, so that the radius users are put into the netshow
(unprivileged) and netedit and sudo (privileged) groups at login.

A lot of restructuring went in as part of that, and cleaned up some
longstanding bugs, including return values for the getpw* routines.
Also cleaned up some whitespace issues.

Also renamed some globals (debug, min_uid, init_common()) that might
collide with other programs, so that when I build unstripped and
normal visibility shared libs, they won't collide with programs
calling the functions (saw this with "debug" and bgpd, for example).

0 files changed, 0 insertions, 0 deletions