[OpenAFS] Authentication without aklog

Jan Iven jan.iven@cern.ch
Fri, 1 Aug 2014 14:53:31 +0200

On 08/01/2014 01:02 PM, chas williams - CONTRACTOR wrote:
> On Thu, 31 Jul 2014 15:29:47 -0500
> Andrew Deason <adeason@sinenomine.net> wrote:
>> The first time I heard this I was a bit surprised, but that may be just
>> because I'm very used to the 'aklog' approach and find it intuitive. You
>> need to tell the kernel what credentials you want it to use for AFS
>> access; makes sense to me.

Honestly, nowadays this seems to be pretty transparent to our users, or 
more exactly, there is little difference made between "expired Kerberos 
TGT" and "expired AFS token" - of course, credentials can still expire 
at inconvenient times.

[On Linux, our users receive both Kerberos and AFS credentials on login 
(console/ssh/screensaver), ssh forwards the TGT (and gets an AFS token 
on the server side), and we have wrappered "kinit" to do "aklog" as 
well. The batch system will do Kerberos/AFS renewal automatically, and 
we have kerberized cron servers.. all of this since several years. The 
PAM bits need looking at for new Linux releases.]

As such, using a different mechanism to get one from the other is not a 
high priority. Of course, some more automatic/'pure' Kerberos-like 
approach[1] would allow us to remove such customizations, but having to 
run something like gssklogd everywhere would probably offset that gain.


[1]: imagine that the kernel on access to AFS checks whether a token 
exists in the PAG, otherwise triggers a userspace call-out (with same 
environment as the calling process, i.e KRB5CCNAME set) to provide one.