[OpenAFS] Re: Authentication without aklog

[Andrew Deason]

On Fri, 01 Aug 2014 11:32:05 -0400
"Chas Williams (CONTRACTOR)" <chas@cmf.nrl.navy.mil> wrote:

> Having a simple PAM module installed by OpenAFS that runs aklog would
> fix a few complaints (but of course do nothing to fix PAGs).

We already have pam_afs_session... (and others)

> PAM continues to grow in popularity, even modern versions of MacOS use
> it.  The problem with PAM is that system configuration tools tend to
> write over any changes an adminstrator might make.

While I agree that PAM is getting pretty universal on unix, that only
helps if you're tying AFS into your system login process, or something
else that uses PAM. If I or something else manually just obtains krb5
tickets, that doesn't help.

There are indeed systems that _don't use pam_, and have no way to hook
into the authentication mechanisms. Even in such systems, krb5 is
commonly a standard choice; integrating AFS access into those is a major
headache. Integrating anything else that uses krb5 is not (or at least,
much less so). 

> >We can do a userspace upcall on any platform; that's not the hard
> >part...
> 
> Yes, but it's mostly useless since it doesn't preserve any existing
> security context.  Unless your kinit puts the tickets in a well known
> (and easily read) location, which somewhat defeats the purpose of
> strong authentication, an up call to afsd is mostly useless.

For FILE: ccaches, I don't see how using the request-key infrastructure
makes things any better. For keyring ccaches, sure, we'd probably have
some keyring-specific logic along those lines to support keyring
ccaches, but the idea in general is not hinging on Linux-specific
behavior.

Guessing where the tickets are on disk works quite well for *gssd
implementations. It doesn't work for all situations, but it works very
well for some/most. Alternatively, you can have aklog explicitly tell
the kernel which ccache to use (the 3rd option in the OP).

-- 
Andrew Deason
adeason@sinenomine.net