Keytab-based initiator creds design

[Russ Allbery]

Simo Sorce <simo at redhat.com> writes:

> Well daemons do not typically log in, so they have no ccache, for real
> users, I am not sure it would be a suprise it might, but I think daemons
> that run under root or a real user ID really SHOULD set the KRB5CCNAME
> env var always, it is just wrong not to do that.

Daemons that setuid can have some problems with using KRB5CCNAME, but
other than that, I agree.  However, I'm a little dubious that the
statement that daemons do not typically log in will continue to be the
case.  We're already seeing a lot of reasons why it would be nice to have
PAM automatically obtain Kerberos credentials for cron jobs, for example.
(Think access to AFS, authenticated NFS shares, or transparent
authentication for LDAP queries.)

A pattern that we use *heavily* here is to have a k5start job run via
daemontools or runit or systemd or upstart or some similar tool that
maintains a persistant ticket cache, and then a whole ton of daemons, cron
jobs, remctl backends, and other scripts that use KRB5CCNAME to point to
that ticket cache.  But I'm not actually that happy with that pattern, in
part because if I also want to get AFS tokens, I have to mess about with
setpag and other nonsense.  I kind of want PAM to just solve this problem
for me: to be able to open a new session from the script and end up with
Kerberos tickets, AFS tokens, and any other credentials I need and have
them cleaned up automatically for me afterwards if appropriate.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>