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-krb5lists.netexpress.net.

Regards,
Steve Langasek
postmodern programmer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE79/rbKN6ufymYLloRAnQ3AKC+Svfb5vU0MPE1i9AvbCZIZ9OnugCfeeKF
+0pnZN1jGvfvzejFgWA2O+k=
=iTNy
-----END PGP SIGNATURE-----

_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]