A /bin/login that does not prompt for basic authentication is called /bin/su. Part of the problem is that telnetd does some kinds of authentication, but not basic. That's historical: at first there was only basic-over-cleartext authentication and it wasn't part of the protocol standard; when more sophisticated authentication support had to be added it had to be done at the telnet protocol, where it didn't use to be. So, ok, have telnetd exec /bin/su when authentication is successfully done by telnetd and have it call /bin/login (or a BBS, or whatever) when telnetd does no authentication. /bin/login and /bin/su should provide options or environment variables such that telnetd and other callers can pass various bits of useful information to login/su, such as wether the tty is secure, what kind of authentication was performed and so on. Then /bin/login and /bin/su can handle authorization as well as environmental issues. /bin/login would also perform basic authentication, as it does now. PAM (and PAM_KRB5) would only be called by /bin/login and /bin/su. /bin/login would call pam_authenticate() and /bin/su wouldn't. Both would call PAM's account/session management functions and PAM_KRB5's session management would handle renaming/chowning of the user's credentials file as well as setting KRB5_CCNAME. If there were to be a pam_authorize() call, again, only /bin/login and /bin/su would call it; telnetd would just not use 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 > --
