Ivan, On Sun, Nov 18, 2001 at 02:13:40PM +0100, Ivan Popov wrote: > I have found some problem in the specification (or is it just my poorly > equipped brain's problem?). Sorry if I missed a relevant discussion on the > list. > pam_setcred() might be called either before or after session > initialization. The docs > (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-3.html) > say: > "It is usually called after the user has been authenticated, > after the account management function has been called but before a > session has been opened for the user." > That is, no *enforced* order. > In other random pam-docs on the net I read even that "pam_setcred() is > usually called after a session has been opened"... > But then, there are things we may want to do by session pam-modules, > that need credentials - to be established by other modules, like pam_kcoda > that needs kerberos credentials. If I stack the modules like > auth pam_krb5.so > session pam_kcoda.so > It may work and may not work depending on when an application calls > pam_setcred(). And when the application does it the other way around, > I have no possibility to make it to work with kerberos and coda, > without combining both modules into one (or providing them with > peer-to-peer knowledge inside pam framework) - thus creating unnecessary > complications in development and support, totally against the idea of > modularization. > The problem might go away if we demand that > "pam_setcred() has to be called after successful authentication and before > pam_open_session()" Having worked extensively with pam_krb5 and the issues you describe, I definitely believe this should be changed from a "can/should" to a "must". The change will ultimately be driven by application writers who need to support the complexities of Kerberos-like systems; I think more and more applications are doing things the right way now, precisely because of Kerberos. I also know there has been some discussion of using a standard pam_data name for storing an in-memory ccache so that other Kerberos-dependent modules can take advantage of credentials as needed. If memory serves, there was a reason that this was definitely needed by pam_afs. Further discussion of this plan would be welcome at pam-krb5@lists.netexpress.net. Regards, Steve Langasek postmodern programmer
Attachment:
pgp00018.pgp
Description: PGP signature
