On Fri, Sep 14, 2012 at 10:58 AM, Matt Garman <[email protected]> wrote: > On Tue, Sep 11, 2012 at 9:21 PM, Booker Bense <[email protected]> wrote: >> On Tue, Sep 11, 2012 at 12:32 PM, Russ Allbery <[email protected]> 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@REALM and foo/cron@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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
