On Tue, Aug 22, 2000 at 04:22:43PM -0500, Steve Langasek wrote: > 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. Agreed. And speaking of preventing the exchange of passwords in cleartext over the network, it would be nice if there were a way to indicate to PAM the security of the session/tty (i.e., that it is or is not encrypted). See my last post on XSSO. > > 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. But even that condition is not met in some cases. E.g., Solaris. > 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. Ok. Though I think it would be nice if: a) there were a way of specifying the items that uniquely identify this session (tty/rhost for many apps), and b) PAM could save and restore state as needed. Most items (excluding auth tokens), the PAM env variables and the pam_data needs to be saveable and restoreable. The pam_data cleanup callback is the perfect place to have modules deal with saving pam_data combined with a new module method for restoring saved pam_data. Heck, throw in an enumeration API and such a system would, in fact, be better than UTMP and UTMPX. Well, if implemented :) > Steve Langasek > postmodern programmer Nico --
