[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

PAM and /bin/login, acct_mgmt() vs authenticate()

So, I've been thinking about how /bin/login should interact with PAM,
checking with our Solaris 2.6 source code and looking at the use of
pam_sm_authenticate() vs. pam_sm_acct_mgmt() in LinuxPAM.

One thing I realize is that several LinuxPAM modules perform account
authorization checks in pam_sm_authenticate() rather than in
pam_sm_acct_mgmt(). I think this is a mistake.

Consider how, say, kerberized telnetd should interact with /bin/login
when a user telnets in and authenticates via Kerberos. Since the user is
already authenticated one might want to configure telnetd to call
/bin/login with -f as an argument. Login's -f argument means "skip
authentication", but certainly not authorization.

Indeed, on Solaris /bin/login does not call pam_authenticate() if -f was
specified and euid == 0. But pam_acct_mgmt() is called regardless.

So, for example, pam_shells does not provide a pam_sm_acct_mgmt()
method, so kerberized telnetd as described above would skip the
pam_shells checks.

I've seen at least one LinuxPAM module whose pam_sm_acct_mgmt() is the
same as or calls pam_sm_authenticate(). For modules that only perform
account management and authorization functions it might be best to
always do so. The reason being that most PAMified apps probably only
bother using pam_authenticate() and skip the rest.

I'm also mystified by the number of modules that provide noop
pam_sm_setcred() functions, instead of not providing any.

Perhaps /bin/login's ideal interaction with PAM should be documented.

Perhaps the usage pam_sm_authenticate() vs. pam_sm_acct_mgmt() should be
better documented as well.

The /bin/login / PAM interaction sequence for the successful login case
should probably be:

 - process options
 - call pam_start()
 - call pam_authenticate() unless -f && euid == 0
 - call pam_open_session() to deal with utmp, logging, auditing, tty ownership
 - setgid(), setgroups()
 - call pam_setcred() to establish creds
 - setuid()
 - pam_end()
 - cd to the user's home directory
 - exec() the user's shell

I'm embellishing. I'm leaving out some details :)  A lot of things that
could be taken care of by PAM are not left to PAM in Solaris 2.6's
/bin/login. I do think that pam_open_session() can deal with all those
things... Where pam_close_session() is called is a different issue...

Also, pam_setcred() really ought to have a flag or two so that PAM could
handle calling setgid()/setgroups()/setuid(). This way PAM apps would
call pam_setcred() two or even three times to complete the process of
becoming the user.

Finally, the getpwnam() API family sucks. It would be much better to
have an API where a user's profile can be accessed attribute-byattribute
rather than in one static, never changing struct. If PAM could provide
such an API, so much the better.

XSSO looks good!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []