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

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



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





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