kerberos & cron - specifically nfsv4 w/sec=krb5p

[Booker Bense]

On Fri, Sep 14, 2012 at 10:58 AM, Matt Garman <matthew.garman at gmail.com> wrote:
> On Tue, Sep 11, 2012 at 9:21 PM, Booker Bense <bbense at gmail.com> wrote:
>> On Tue, Sep 11, 2012 at 12:32 PM, Russ Allbery <rra at stanford.edu> wrote:
>>
>>> Either NFS doesn't understand matt/cron as a user, or the local daemon
>>> that handles user credentials can't find the tickets.  I believe you do
>>> have to be careful about how you name the ticket cache for NFS to pick it
>>> up.
>>>
>
>> [1]- If this can be done on the client side, then it pretty much
>> entirely defeats much of
>> the security model of NFSv4. If you do it on the server side you need
>> a many to one
>> mapping, I don't know enough about idmapd.conf to know if that's
>> practical or not.
>
> Can you elaborate a bit on why, if done on the client side, it defeats
> the NFSv4 security model?  (Honest question, no doubting your
> statement.)

Well, one of the primary drivers of NFSv4 is the security aspect of
not allowing
root on a client to impersonate anyone w/o access to credentials. If I can map
any principal to a uid on my machine, then the whole thing is defeated.

Root can still impersonate you if you have a tgt on the machine ( and
it more or less
has to to make NFSv4 work. ).

You should probably just ignore this, as I am talking of the top of my
head and haven't
really dug into gory details of which daemon runs where.



>
> How would using idmapd on the client side as you suggest be
> similar/different from Russ's earlier suggestion of exporting the
> user's key in kadmin.local with -norandkey?
>

If you copy the key into a keytab, that's the moral equivalent of putting
a password in a file to use to get kerberos tickets when you need them.

Idmapd is the program that looks inside the kerberos bits, reads the principal
and then decides which unix account/uid to map that principal to when accessing
the files.

The file system only knows about uid's, kerberos only knows about
principal names.
Somehow you have to map things back and forth. The "default" scheme is to strip
off the realm and attempt to call getuid(principal).

If you use a separate principal for cron jobs, you need to map that
kerberos principal
to a unix uid; ideally, the same uid as the principal w/o the /cron addition.

It's very important to remember that the connection between

foo at REALM

and

foo/cron at REALM

is entirely in our minds. Kerberos doesn't make any connection and any
software that uses
kerberos doesn't make any connection unless we tell it to.

- Booker C. Bense