Nicolas Williams wrote: > > On Fri, Aug 18, 2000 at 04:36:34PM -0400, Nicolas Williams wrote: > > On Fri, Aug 18, 2000 at 04:09:48PM -0400, Nalin Dahyabhai wrote: > > > 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(). > > In fact, telnetd et. al. on Solaris only set the PAM_TTY and PAM_RHOST > items before calling pam_close_session(). > > > I think this is fine, provided that PAM, or, rather, the various PAM > > modules can retrieve the necessary state given just those items. > > > > So, on Solaris, pam_close_session() is called by telnetd and friends, > > not by /bin/login. > > I kind of like this ability to use those items to retrieve state and > close the session later. As long as it works... > This exactly thing was looked for in shadow-utils implementation also, and that implementation taken the same approach for solaris as solaris's own login. This very unclear and at least unreliable to close pam (pam_end) after opening session and to call pam_start again at the end. There may be some module's internal state stored as pam_item's that will be lost then pam_end will be called the first time. Also some items will that was available to login only (if kerberos does not used, then telnetd have no way to see the username). And this is not clear to me how both (login and telnetd) should iteract with each other in this case, and not having additional login process as it currently implemented in linux. Only one (totally different) approach seemed to be appropriate here -- to avold usage of login at all (!) -- in case of pam, login is _very_ simple (or at least should be -- note that I also think that all [uw]tmp[x]/lastlog/etc manipulations also belongs to pam modules, not each application), and can be implemented just easily in telnetd. In this case, all things will be in own place (as I hope -- I may be wrong), and we will have only two processes to do things clean/right, and there should be no strange flags for login (i.e. do not do auth) in this case. There are still some possibilities to have a bugs in telnetd code that is not good from security point of view (buffer overflows together with assess to security-sensible data in pam), but this is not _so_ bad since telnet protocol should have correct implementation already, isn't it? One another issue with this (not regardless of telnetd+login iteraction, but about pam_"reopen" between start/end of session -- there _may_ be a need to have some module have some file(s) opened during the whole session (this _is_ questionable, but anyway: imagine the chrooted process (that by some reasons have no fork/wait as linux's pamified login), or (also without fork/exec) that will drop root privileges -- in this case we will lost privileges/ability to reopen say wtmp files to complete session; this _may_ be achieved by just opening the wtmp file at pam_open_session and close it in pam_close_session, so we does not need any additional privileges to close session). Again -- this _is_ questionable behavour that have some more potential disasters, but who knows if it will be needed (another approach to achieve the same effect without that disaster is to fork/wait or to create additional process inside a pam module for exactly that purpose). Regards, Michael.
