On Sat, May 12, 2001 at 08:21:33PM -0400, Theodore Tso wrote: > On Sat, May 12, 2001 at 05:14:20PM -0400, Sam Hartman wrote: > Remote filesystems have always been problematic, since often you > *must* want to establish credentials before you can access the user's > home directory. So saying that pam_setcred happens after the > pam_session is established is problematic. Given the flags argument to pam_setcred(), one could argue that pam_setcred() ought to be called before and after pam_open_session() and after pam_close_session(), with a different flag each time... > In practice, the way this problem is handled today is to have the > Kerberos and Pam modules establish credentials using a session hook, > and not using pam_setcred. This *does* work, but arguably one can ask > then what's the point of having pam_setcred? The Kerberos PAM module we're using does, indeed, have an option, "setcred_in_auth", to call pam_sm_setcred() before returning from pam_sm_authenticate(). We added this to deal with a buggy dtlogin that was calling pam_end() before calling pam_open_session() and pam_setcred() on a new pam handle. It also has an option, "pw_exp_int_auth", to cause it to allow krb5_get_init_creds_passwrod() to drive the changing of expired passwords from within pam_krb5:pam_sm_authenticate(). [...] > The fact that some applications are calling pam_set_cred() and > pam_open_session() in an indeterminate order is his justification for > changing things so that the "right" order is the exact opposite of > what is currently documented, and which matches the order used by > login. (i.e., calling pam_setcred() before pam_open_session().) Hmmmm, those apps are just buggy. The interesting thing is that some apps may not really have a concept of "session". Also, utmp/wtmp/lastlog handling, arguably belongs in pam_unix, but most implementations still leave some or all of that to the application. > I'd argue that it's probably better, in terms of Sun/DCE > interoperability to say that the "right" order is what's currently > documented, both in the Sun and Linux-PAM documentation, but to > deprecate the usage of pam_setcred. Specifically, in the case of > things like Kerberos and AFS where it's necessary to establish > credentials early, that's it's documented and recommended that > credentials establishment take place during pam_open_session(). Of > course, those applications like login which are calling pam_setcred() > in the wrong order should be fixed, and the documentation in the > application writer's guide should probably be strengthened to match > the language in the pam module writer's guide. Well, here I'd say PAM modules need to be able to communicate; pam_krb5:pam_sm_authenticate() should store creds in pam data which pam_afs:pam_sm_*() can then retrieve and use as needed later. And this is not the only time that [Kerberos] creds may be needed before pam_setcred() is called. Consider ActiveDirectory, where you may need to have [a user's] creds before accessing the directory; in this case what's needed is tighter integration between PAM and NSS -- heck, throw NSS out and start anew because getpwnm() et. al. are really long in the tooth now. But pam_setcred() should not be deprecated. It still has a role to play, e.g., in screen lockers, which can call it to reinitialize creds when users unlock their screens, or when it's called at the end of a session to destroy creds (though pam_close_session() could do that too). I would like additional flags to pam_sm_setcred() to indicate wether to set credentials in the current meaning of the term, or "kernel" process credentials, so initgroups() and setgid()/setuid() can be moved into PAM. A careful calling sequence convention would be needed, and perhaps this functionality should be in a separate method altogheter, rather than indicated by a flag to setcred(). > - Ted Nico --
