On Tue, 15 May 2001, Nicolas Williams wrote:
> > My understanding of non-filesystem-based credentials caches is fairly low, but
> > I was under the impression that with Kerberos 5 it's possible for the PAM
> > authentication module to make the TGT available to the process before it's
> > written out to its final file location. This means that, with a proper
> > interface (i.e., using pam_getenv()), libpam-openafs-session could make use of
> > the Kerberos credentials before pam_setcred() is called.
> 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.
> 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.
> 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.
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.
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.
> > 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.
> > or
> > auth sufficient pam_unix.so
> > auth requisite pam_krb5.so try_first_pass
> > auth optional pam_openafs.so
> This would not work UNLESS users who DO have Kerberos accounts also have
> no valid Unix password (e.g., "**KERBEROS" in the crypted password field
> of the user's pwd entry) because if pam_unix:pam_sm_authenticate()
> returns PAM_SUCCESS then pam_krb5 and pam_openafs would not be tried.
Correct.
> 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.
> 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?
Regards,
Steve Langasek
postmodern programmer
