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 PAM. Nico 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 > --
