kerberos & cron - specifically nfsv4 w/sec=krb5p

[Matt Garman]

>> 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. ).

In our particular case, what we want out of NFSv4 is the stricter
controls over mounting (i.e. beyond simple IP addresses, Kerberos auth
in NFSv4 case) and also encrypted data streams.  We actually don't
need the per-user authentication (at least no more than previous NFS
versions offered).

> 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.

One thing that is not clear to me is how the idmapd config must be the
same/different on the server and the client.  I see references in this
thread and in general on the web, but can't find any specific detail
on idmapd client versus server.

At any rate, I hacked my idmapd.conf: I added "GSS-Methods = static"
under the [Translation] section, and "mattcron at OURREALM.COM = matt"
under the [Static] section.  I did this both on the server and client
side.  (I'm using "mattcron" instead of "matt/cron" for now.)

I then set up a cron job under user "matt", which was basically this
every minute:

kinit -k -t <keytab_file> mattcron ; touch
/path/to/nfsv4share/file.`date +\s` ; kdestroy

And it worked... for about forty minutes, after which, it started
failing with "permission denied".  I didn't change anything in that 40
minutes, I'm sure!  I got it working, and went to work on some
unrelated task.  Came back, and my mailbox was full of cron failure
messages.

Even now, if I login, and manually do a "kinit -k -t <file> mattcron",
I get permission denied on that share.  I have a folder on that share
with 777 permissions: if I create a file here, it shows up as owned by
"nfsnobody".  So somewhere along the way it appears my mapping broke.

If anyone has any thoughts, I'd be happy to hear them.

-Matt