Question on k5start daemon-related example in k5start manual

[Russ Allbery]

Holger Rauch <holger.rauch at empic.de> writes:

> thanks a lot for your detailed explanation. What I forgot to mention:

> - I initially log in to the box (NFSv4 client) via ssh, which causes
>   the following
>   
>   *) Kerberos tickets are obtained
>   *) the home dir is mounted with automount via NFSv4
>   
> - From that interactive shell I would like to use k5start as a wrapper
>   so that the process(es) started via their init script can still write
>   to the NFSv4 file system and don't get "Permission denied" when the
>   tickets expire.

I don't think this works.  I think you're going to need to do something
trickier that invokes k5start -H in the user's session periodically, like
using a shell function for the prompt that checks elapsed time from the
last time k5start -H ran.  (Alternatively, of course, convince all the
users to run something that does this kind of thing for them.  There is a
tray application for GNOME that does this, for example.)

> Is it possible run daemon-like processes indefinitely (provided there's
> no core dump etc.) using k5start? (Sorry for explictly asking this, but
> it's not clear to me from the examples I've come accross on your home
> page).

Yes, but only if you have a keytab.  For a user, you don't have a keytab
(which would be equivalent to storing the password for that user on disk),
so that doesn't really work.

> Do I have to take any additional measures when a daemon accesses a NFSv4
> mounted filesystem via automount (That is, do I have to add additional
> principals to my keytab file)? (Currently, only the corresponding user
> principal is in there).

The only thing that should be in your system keytab file is the host/* key
for the system, normally.  If you want a daemon to be able to access
Kerberized NFS with authentication, you'll need to create a keytab for
that daemon to use with a principal that has appropriate access to NFS.
Usually you want to store that keytab somewhere other than /etc/krb5.conf
since normally you don't want to run daemons as root, and the keytab file
needs to be readable by whatever user the daemon runs as.

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