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

Re: PAM and Kerberos

It helps to RTFM. I just read up on PAM and looked at our Solaris source
(we have a license for 2.6).

I realize now that I was overreacting. The pam_acct_mgmt() call is the
really coarse authorization function I was looking for. And it seems to
me that the right way to handle chowning of the credentials file is to
do it in pam_sm_setcred() in PAM_KRB5.

/bin/login should have a flag that indicates that the user has already
been authenticate and so /bin/login should not perform basic
authentication (but this flag should only be honored if uid == 0).

/bin/login should call pam_authenticate() for basic authentication (or
not if the user is already authenticated).

/bin/login should set the primary and suplementary groups, then it
should call pam_setcred(), giving PAM_KRB5 a chance to setup the
credentials cache, THEN /bin/login should call setuid().

If anything fails upto and including setuid() and login must exit(),
then pam_end() must be called. PAM_KRB5 can use pam_set_data() to
register a function to be called back when pam_end() is called and then,
if error_status == PAM_ABORT, remove the credentials file.

The key is that pam_setcred() be called prior to setuid() and that
PAM_KRB5 be given a chance to destroy any credentials files if the login
process should have to be aborted.

So, on Solaris, for example, whose /bin/login appears to do the Right
Thing (tm), a suitable PAM_KRB5 is all that is needed. This leads me to
think that login.krb5 should not be necessary on platforms that support


On Sat, Aug 12, 2000 at 06:13:46PM -0400, Jeffrey Altman wrote:
> The reason that /bin/login must be replaced is to properly handle the
> credentials cache file.  The credentials cache file is created by
> telnetd as 'root' prior to the knowledge of the actual user account
> that will be used for login.  When the client authenticates with a
> prinicipal but wants to login as an alternate local-account, login is
> the process that knows what the new account name will be.  Therefore,
> only the login process is capable of performed the chown()/chgrp() on
> the user's credential cache file.
> We have a similar problem with the .Xauthority file when X Windows
> System Data Forwarding is implemented.  
> I agree that it would be nice to remove the call to a custom login.
> Perhaps it would be possible to integrate the username/password
> prompting functionality into telnetd so that telnetd knows who the
> real user is.  Then the OS specific /bin/login can be called to handle
> the user environment, profile, shell, ... execution.
> > 
> > With reference to the recent discussion of PAM and Kerberos on the
> > krbdev@mit.deu list (see http://www.mit.edu:8008/menelaus.mit.edu/krb5dev),
> > I'd like to make a few observations:
> > 
> > PAM appears to be used for authorization of login access sometimes, that
> > is, there are modules which perform login authorization checks as part
> > of authentication.
> > 
> > I think this is bad. Authorization should be a separate call in the PAM
> > API, even though each application and module will have different
> > authorization needs and PAM cannot cater to all of them. Any
> > authorization checks that PAM could possibly offer must be fairly
> > coarse, and, really, just gate keepers.
> > 
> > Now, as for Kerberos and kerberized telnet/ftp and replacing /bin/login,
> > here's what I think is the problem:
> > 
> > 1) no state is kept across the telnetd/login exec() boundary,
> > 2) normally login handles [basic] authentication,
> > 3) but with GSS-API/Kerberos it is telnetd that handles authentication,
> >    and login then handles environment issues (becoming the user,
> >    exec()ing the user's shell, ...)
> > 
> > We really ought to have a way of dealing with basic vs. pass-through
> > authentication, everything else remaining the same.
> > 
> > Essentially, we ought to separate handling of pass-through
> > authentication from the kind of authentication that PAM, as it stands
> > now, can provide.
> > 
> > One way to deal with this might be to remove the telnetd/login
> > exec() boundary when pass-through authentication is involved, by
> > absorbing some of login's functionality into telnetd. Already there
> > little or no state to keep when doing basic authentication, since login
> > handles prompting the user for his/her basic credentials.
>                   Jeffrey Altman * Sr.Software Designer
>                  The Kermit Project * Columbia University
>                612 West 115th St * New York, NY * 10025 * USA
>      http://www.kermit-project.org/ * kermit-support@kermit-project.org

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