On Mon, May 14, 2001 at 05:22:04PM -0500, Steve Langasek wrote:
> Hi Sam,
>
> On Sat, 12 May 2001, Sam Hartman wrote:
[...]
> > But then it seems that it would be a session level activity to mount a
> > homedir, or create a homedir, or in my case let AFS know about tokens.
> > None of these activities have anything to do with authentication, but
> > all of them could depend on having access to network authentication
> > made available in setcred. For example, I could be using a networked
> > filesystem with authentication to mount the homedir. I could desire
> > to log into a database to get information on the initial contents of
> > the homedir, authenticating to the database with the network identity
> > of the already authenticated user. In the AFS case I need the
> > credentials to convert them into tokens.
>
> 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)?
Hmmm. I wish there were another mechanism other than env vars and prompt
conventions for communicating information to the app from PAM
modules...
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("ccace")...
[...]
> It's true that AFS has no authentication value, but it's also the case that
> this module's functionality -- establishing credentials for filesystem access
> -- can be seen as falling snuggly within the responsibilities of the
> pam_setcred() function. An authentication module which returns an
> unconditional PAM_IGNORE to pam_authenticate() and does all the real work in
> pam_setcred() is therefore not out of the question, IMHO.
Indeed. I have such a module for other unrelated purposes.
Remember, a module's pam_sm_setcred() should always be called
regardless of wether that module's pam_sm_authenticate() was called, so
long as the app calls pam_setcred().
[...]
> > I really want the Kerberos module to be sufficient because I want to
> > allow users with local accounts to use pam_unix.so, so I need to make
> > pam_unix.so be more than just optional so people with neither local
> > accounts nor Kerberos authentication will fail. However, the openafs
> > auth setcred call needs to happen after the Kerberos setcred call so
> > it can get to the credentials. Sadly, if the sufficient Kerberos
> > module succeeds no other modules will be tried. To me, this is a
> > fairly strong argument that AFS tokens cannot be an authentication
> > activity--you want them to get set up even if you have already
> > established sufficient authentication beforehand.
>
> Do either of these configurations meet your needs?
>
>
> 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.
> 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.
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.
But make sure that pam_openafs:pam_sm_authenticate() returns
PAM_IGNORE!
> My own impression is that the second case provides the semantics usually
> desired by an administrator (give precedence to local accounts, ignoring
> network databases on success), but there's always the possibility that you
> want to query the network database first so that those with accounts in both
> databases aren't locked out from using network filesystems. This could lead
> to the simple policy that users who have network credentials shouldn't have
> local passwords, but even that may not be desirable to the admin for whatever
> reason.
E.g., legacy apps that don't use PAM and expect crypted passwords in pwd
structs.
> In that case, I think the first config above may do the right thing,
> assuming a pam_openafs module that returns PAM_IGNORE from
> pam_sm_authenticate(). I don't suggest taking my word for it, though, as my
> memory is spotty when it comes to the exact behavior of the PAM configuration
> directives; it may be that both pam_krb5 and pam_unix must succeed in this
> configuration.
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.
> Regards,
> Steve Langasek
> postmodern programmer
Cheers,
Nico
--
