Re: Why should setcred be called after session open?

[Nicolas Williams <Nicolas Williams ubsw com>]

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
--