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. Here's some specific steps we might take to get us there: - separate most of the /bin/login.krb5 environment code into a library that telnetd/ftpd/etc... can link against; - let telnetd/ftpd/etc... use the login.krb5 library calls to avoid having to exec() login, but only when the remote client was authenticated with suitable credentials other than basic (username/ password won't do; Kerberos, NTLM, Sun's Diffie-Hellman system will do); - let telnetd/ftpd/etc... exec /bin/login when the remote client is unable to provide suitable authentication credentials and inform /bin/login as to wether the connection is secure (encrypted) or not. /bin/login should decide wether or not to prompt for a username/password and use PAM to authenticate that; - add a pam_authorize() call to the PAM API. This call must be rather generic and should take typed data as arguments so that the individual PAM modules can figure out if they can do anything with the arguments; - let telnetd/ftpd/etc... call pam_authorize to authorize login access to the host, but only following pass-through authentication - let /bin/login call pam_authorize to authorize login access to the host, after successful authentication; BTW, it appears that Sun is already doing something along these lines, though without separating pam_authenticate's authorization function. Essentially, Sun's PAM_KRB5 has an option, 'acceptor', which causes it's authenticate() function to return PAM_SUCCESS without any further ado. This is used in combination with application names specific to kerberized login services, so that login can skip basic authentication when called from kerberized services. Or so I guess; the docs[1] are rather skimpy at this time, and Sun's telnetd/login might be passing Kerberos ticket/authenticator/tgt to PAM through some additional enhancements, for all I know. Nico --
