On Tue, May 15, 2001 at 10:39:40AM -0500, Steve Langasek wrote:
> On Tue, 15 May 2001, Nicolas Williams wrote:
> > pam_getenv()? Are you saying that pam_krb5:pam_sm_authenticate() should
> > create an interim memory ccache, use pam_getenv(KRB5CCNAME) then later
> > pam_krb5:pam_sm_setcred() should re-create the ccache and reset
> > pam_getenv(KRB5CCNAME)?
>
> Yep.:) It's the cleanest way -- this way, once we have the credentials, we
> always have a KRB5CCNAME that points to them.
*mumble*
Ok, we'll think about implementing that at some point. Currently only
setcred() does it, and with the final ccache, not the memory-based
ccache used in between authenticate() and setcred().
> > Hmmm. I wish there were another mechanism other than env vars and prompt
> > conventions for communicating information to the app from PAM
> > modules...
>
> Use of the KRB5CCNAME env var is a standard mechanism for communicating
> Kerberos ccache information. It is, however, inappropriate for PAM modules to
> modify the calling application's environment in this manner. Imagine the
> chaos that would ensue if you had an asynchronous authentication server
> processing 10 Kerberos logons at the same time! So a PAM module that needs to
> use environmental variables should be able to find them in the application's
> environment, but should give precedence to local PAM env vars if present.
I didn't mean calling putenv() directly! What made you think I did? :)
> > Well, in the case of a pam_afs module this wouldn't be necessary as
> > pam_afs:pam_sm_open_session() can reference pam_get_data("ccache")...
>
> At which point we're even worse off, because you then have a non-standard
> interface used to pass data between these two particular PAM modules.
> pam_get_data() really ought only be used for data specific to a single module.
> For passing Kerberos ccache information, $KRB5CCNAME is the standard
> mechanism. We're simply mirroring this by making it available as a PAM env
> variable instead of an application env variable.
Well, I think PAM modules will find themselves communicating one way or
another with each other. Since AFS uses Kerberos it does make sense for
there to be a convention by which PAM_KRB5 and PAM_AFS communicate --
wether they use PAM data or PAM env vars is not terribly important, I
suppose.
> We need to be doing pam_putenv(KRB5CCNAME) regardless of pam_openafs, as this
> is the mechanism PAM defines for exposing env vars to the application.
The question is wether to do that with the temporary memory ccache in
pam_krb5:pam_sm_authenticate(). Till now only pam_krb5:pam_sm_setcred()
did pam_putenv(KRB5CCNAME).
Not that it matters that much -- the MIT krb5 memory ccache uses SysV
shared memory, which means the ccache is left lying around in the system
if it's not explicitly deleted (ugh!). I'd rather there were an
optionally anonymous mmap() memory ccache that could be guaranteed to go
away when the last process to have it mapped exits.
> Attempting to set the env var directly from the PAM module breaks
> encapsulation, and leaves the application writer stranded. It should be up to
> the application writer to decide how PAM-provided env vars are handled.
Right. I never meant that pam_krb5 should call putenv() directly.
> > > auth required pam_krb5.so
> > > auth optional pam_openafs.so
> > > auth sufficient pam_unix.so try_first_pass
>
> > This would require that all users have Kerberos accounts.
>
> Ok -- wasn't sure how 'required' required would be here.
Very.:)
[...]
> > auth required pam_krb5.so ignore_unknown_upn
> > auth optional pam_openafs.so
> > auth optional pam_unix.so use_first_pass
>
> > Should work. Note that pam_unix could be optional or sufficient -- makes
> > no difference in this case.
>
> Hmm. I would not expect that a module listed as 'optional' would contribute
> to the return value of pam_authenticate(). Either way, listing pam_unix as
> 'sufficient' seems more intuitive to me.
A single optional module that returns PAM_SUCCESS will suffice for
pam_authenticate() to return PAM_SUCCESS if there are no required or
requisite, or, if there are any required/requisite modules and they all
returned PAM_IGNORE.
> > We're really pushing the limits of pam.conf here. This is why we're
> > resorting to making modules that have options to specify that they
> > return PAM_IGNORE in some circumstances. Were it not for PAM_IGNORE we'd
> > have to resort to writing monolythic modules that absorb the
> > functionality of all the modules we wish to stack.
>
> > Sigh.
>
> > This is why I argue for a boolean expression system for specifying PAM
> > stacks.
>
> We do have much more complex config file semantics available under Linux-PAM.
> Trouble is, I think most people are hesitant to use the extensions because of
> the portability issue - that, or the semantics are so complex that most people
> who would like to use them can't get their minds around them?
Do you? I don't think so. Linux-PAM's module config system is not
different than Sun's, other than config-file-per-service difference.
I.e., you're stuck with required/requisite/sufficient/optional -- that
is waht leads to playing with PAM_IGNORE...
> Regards,
> Steve Langasek
> postmodern programmer
Cheers,
Nico
--
