[OpenAFS] Re: Authentication without aklog

[Andrew Deason]

On Fri, 1 Aug 2014 11:56:34 +0200
Markus Koeberl <markus.koeberl@tugraz.at> wrote:

> One problem regularly occurs is that a user underestimated the time
> the simulation will run and at the end it is not possible to save the
> data into AFS. A solution where it is not necessary to run aklog
> inside the PAG would I guess solve this problem.
> Because the common way people run their simulation is the following:
> * ssh to host
> * screen
> * get a long lasting kerberos ticket
> * run a pagsh script which creates a copy of the kerberos ticket and
> runs aklog
> * start the simulation, if possible from time to time run kinit -R;
> aklog in the simulation

My suggestion for these cases is for the site to have some command for
running batch jobs, which would set up a new pag and run krenew/'kinit
-R' in. That is, instead of running 'screen', you can tell your users to
run something like 'tugraz-batch-screen', which is a script that does
something like: run 'pagsh', copy the krb5 credentials, and run
'krenew', and have krenew run 'screen'. That way, the processes inside
the 'screen' get credentials for longer and the user doesn't need to
know too much about what's going on.

I've mentioned this to someone before, I think; I don't remember if it
was to you :)

Of course, that's just a suggestion for what you can do right now with
existing client behavior; it would be nice if you didn't have to go
through all of that.

> If the kerberos ticket runs out of lifetime it is possible to login to
> the host an replace the kerberos ticket manually. But it is not
> possible to run a shell inside the right PAG

It is actually possible to set new credentials for an arbitrary PAG, but
doing so I believe is unintentional and "not supported" and could change
at any time, etc etc. At least one site relies on this functionality,
though, and so providing a supported interface for doing this is on my
todo list.

> This sounds like a nice feature which may make life easier for us and
> possible also solve some problems. I do not see disadvantages. Maybe
> somebody can point out some of them. 

The primary disadvantages I think are the extra work to implement this
("is it worth it?"), and any confusion that might arise from the
behavior. Having authenticated access to /afs without explicitly saying
"authenticate me to afs" would be surprising to existing afs users, and
in some situations you may want to keep a context unauthenticated.

For example, if global rpc.gssd-like behavior is turned on, we'll
probably want some special handling for at least uid 0, so one daemon
running as root wrapped in k5start doesn't cause all root processes to
also gain afs privileges automatically.

There are also some situations where the kernel just cannot refresh your
credentials for you, I think. One such example is the MEMORY: ccache
type, where the krb5 tickets are present only in the memory of some
libkrb5 structures in the calling process. As far as I know there's just
no feasible way to get at those credentials at all from somewhere else.
Some other ccache types may also be impossible or at least be a little
tricky (like "API:", or some other types that are handled by some daemon
or something).

That can be confusing, since users (and probably most administrators) do
not really think about what ccache type they are using or how they work,
as it's usually set up for you. Ideally we'd work like any other
kerberized application and we can just use whatever KRB5CCNAME our
libkrb5 supports and we don't have to interpret it at all, but this is
one way I believe we must differ at least a little bit.

-- 
Andrew Deason
adeason@sinenomine.net