[OpenAFS] Re: Authentication without aklog
Fri, 1 Aug 2014 10:57:31 -0500
On Fri, 01 Aug 2014 11:32:05 -0400
"Chas Williams (CONTRACTOR)" <firstname.lastname@example.org> 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
> 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
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).