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
