Hi Ted, On Sat, 12 May 2001, Theodore Tso wrote: > 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().) But we are still very much in the "shakedown" phase for many aspects of the PAM API; although the Sun spec has been around for years, it's only now that PAM is becoming widely used that it's practical for large-scale applications of Kerberos and AFS. When everyone was still using pam_pwdb/pam_unix for authentication, there was no problem -- a little slop on the application's part didn't hurt anybody. I'm not convinced that login's behavior doesn't represent one of these slop bugs. We should be very sure that the current spec is *wrong* (and not just inconvenient) before turning the spec on its head and sending currently-compliant apps back to the drawing board. > 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. The problem with deprecating pam_setcred() in favor of pam_open/close_session() is that an application which calls pam_authenticate() MUST call pam_setcred(PAM_ESTABLISH_CRED) from the same PAM handle. This is because a PAM module which acquires credentials as a result of pam_authenticate() may store these credentials as internal state, never making them available to the calling application until the call to pam_setcred(). An application which has called pam_authenticate() also MUST call pam_setcred(PAM_DELETE_CRED) when the 'session' is ended.[1] Of course, this is not rigorously adhered to; there are even some Solaris applications which get the first part wrong (c.f. Nico's comments). Nevertheless, the module writer has a reasonable guarantee that any credentials acquired in pam_authenticate() will be dealt with properly in pam_setcred(). OTOH, an application MAY call pam_open_session() and pam_close_session() with the same pam_handle_t that was used for pam_authenticate(), but is not required to do so; in fact, an application writer is not required to call them /at all/. You also introduce more leeway for foot-shooting maneuvers, because an admin can very easily break his PAM config to not call the suddenly-important session functions; with authenticate/setcred, which are both configured with the single 'auth' line, this is not so easy to do. So while I can agree with the sentiment to simplify the PAM API, I think this particular change would only cause more pain. :) Regards, Steve Langasek postmodern programmer [1] This becomes particularly important, as you can imagine, when pam_setcred() is not a no-op function; leaving Kerberos ccaches and the like on the filesystem is not acceptable behavior.
