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! Nico --
