On Mon, May 14, 2001 at 05:55:11PM -0500, Steve Langasek wrote: > Hi Ted, > > On Sat, 12 May 2001, Theodore Tso wrote: > > 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). To be fair to Sun, these buggy apps are CDE apps, dtlogin and dtsession, neither of which originated at Sun (I think, though their PAMification may have originated at Sun). I've seen CDE source, and I can understand that it would be difficult to add PAM support to CDE without unwittingly introducing other bugs. Some of these bugs have been fixed, others I just filed bug reports for (e.g., long PAM prompts are not wrapped; dtsession does not fully support PAM prompts). > Nevertheless, the module > writer has a reasonable guarantee that any credentials acquired in > pam_authenticate() will be dealt with properly in pam_setcred(). Indeed. > 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. This last argument is not really acceptable -- you can't prevent admins from shooting themselves in the feet -- there are myriads of ways they can do that now. It's one thing to seek to be user fool proof, but admin fool proof?? > Regards, > Steve Langasek > postmodern programmer Nico --
