On Fri, 18 Aug 2000, Nicolas Williams wrote: > On Fri, Aug 18, 2000 at 04:09:48PM -0400, Nalin Dahyabhai wrote: > > On Fri, Aug 18, 2000 at 03:38:47PM -0400, Nicolas Williams wrote: > > > 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. > > > > I think the last time this was brought up on this list, everyone who > > voiced an opinion agreed with that. > So these modules need fixing then? Yes, these modules do need fixing, or at least 'enhancing'. There's at least one scenario where it's been useful to have these modules in the 'auth' stack instead of the 'account' stack, namely to prevent administrative passwords from being sent in the clear across the network when the login will be ultimately rejected. So being able to interleave authorization and authentication functions is sometimes useful, but even so we want to be able differentiate between authentication and authorization -- so we should at least have the *option* of putting pam_shells, etc. in the 'account' stack. > > You can't pam_end() before the shell starts, because you have to call > > pam_setcred(PAM_DELETE_CREDS) and pam_close_session() before you do > > that. For this to work, login forks, handles the last two steps, and > > the parent takes care of a proper PAM shutdown when its child exits. > Hmmm. Well, that's not how Solaris 2.6 does it. > There seems to be an assumption that you can call pam_end() without > calling pam_close_session() and that later you can call pam_start() > again, use pam_set_item to set the relevant items (user, ruser, rhost, > tty) and then call pam_close_session() and pam_end(). I seem to recall this 'assumption' being approved a couple years ago on this mailing list; so it's more or less officially considered safe to call pam_end() and pam_start() between any two other pam calls without adverse effects. Any state that needs to be saved between calls should be found either in the pam items, or in the list returned by pam_getenvlist(). This also means that pam_close_session() can be called by a different process than the one which called pam_open_session() -- *so long as* the first process has some way of getting all of the PAM items and PAM environment variables to the second process. So with telnet, the trick is still making sure that the process calling pam_setcred(PAM_DELETE_CREDS) and pam_close_session() has all the info it needs to identify the session, whether this be /bin/login after fork()ing, or telnetd that's had the relevant information passed to it by some unspecified mechanism. Steve Langasek postmodern programmer
