Kerberized NFSv3 incorrect behavior

[Rick Macklem]

On Fri, 5 Feb 2010, George Mamalakis wrote:

> Dear all,
>
> I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My 
> configuration is based on 
> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My goal is 
> to share filesystems securely through kerberos authentication. Everything 
> works fine, until I try to kdestroy my tickets or kinit to some other user, 
> where the system insists to think that I am the user that initially obtained 
> their ticket. To be more extensive, my story is as follows:
>
[good stuff snipped]
>
>
> and both client and server have the correct entries about each other (and 
> themselves) in their /etc/hosts, so heimdal works just fine.
>
> Both client and server have their respective keytabs stored in 
> /etc/krb5.keytab, and I use two users in my example (that both exist in both 
> systems with the same uid,gid): mamalos and testakis.
>

Unless you have applied the experimental patch, a keytab entry is
meaningless in the client. Without that, it was assumed that "root"
would never "kinit" as anyone. Basically, it was assumed that "root"
would only do the mount and a user, like "mamalos" or "testakis"
would be logged in and kinit'd as that user.

The short answer is that any principal with TGT in the credentials
cache for uid==N will be used to authenticate that user. Once
authenticated, that "handle" for the user can be used until it
expires (up to the server, but usually set to when the TGT that
it found in the credential cache is due to expire).

> So, when I mount the exported filesystem on the client giving:
>
> # mount -o nvfsv3,sec=krb5 server.example.com:/exports /mnt
> # mount
> /dev/da0s1a on / (ufs, local, soft-updates)
> devfs on /dev (devfs, local, multilabel)
> server.example.com:/exports on /mnt (nfs)
>
> and try to access the share:
> # ls /mnt
> ls: mnt: Permission denied
>
> I get the error I am expecting, since root does not have any kerberos tickets 
> assigned, yet. Let's see what happens when I kinit as mamalos:

Yep, as expected.
> # klist
> Credentials cache: FILE:/tmp/krb5cc_0
>        Principal: mamalos at EXAMPLE.COM
>
>  Issued           Expires          Principal
> Feb  5 11:20:49  Feb  5 21:20:47  krbtgt/EXAPMLE.COM at EXAMPLE.COM
> # ls -la /mnt/
> total 8
> drwxr-xr-x   4 root      wheel  - 512  4  Feb 19:03 ./
> drwxr-xr-x  21 root      wheel  - 512  3 Feb 11:27 ../
> drwx------   2 mamalos   wheel  - 512  5 Feb 11:11 mamalos/
> drwx------   2 testakis  wheel  - 512  4 Feb 19:06 testakis/
> # touch /mnt/mamalos/myfile
> # ls -la /mnt/mamalos/myfile
> rw-r--r--  1 mamalos  wheel  - 0  5 Feb 11:22 /mnt/mamalos/myfile
>
> Which is the exact behavior that is expected. Now when I kdestroy:
> # kdestroy
> # klist
> klist: No ticket file: /tmp/krb5cc_0
> # touch /mnt/mamalos/myfilethatshouldnotbe
> # ls -la /mnt/mamalos/myfilethatshouldnotbe
> -rw-r--r--  1 mamalos  wheel  - 0  5 Feb 11:24 
> /mnt/mamalos/myfilethatshouldnotbe
>

Yes, this is a "bug/limitation" in the current implementation. I believe
that "kdestroy" should do some sort of system call to inform the NFS
client that "credentials for uid==N" should be invalidated. This is not
implemented in FreeBSD8 (or Linux for that matter, last I checked).
I don't know if dfr@ was planning on doing this and whether or not he
thinks it is appropriate to do so?

Without that implemented, the "handle" continues to work until the
server expires it, normally when the TGT for "mamalos" would have
expired if you hadn't kdestroy'd it.

> And I can do everything in that share as if I were still mamalos, even though 
> I kdestroyed my kerberos ticket. The same thing will happen even if I kinit 
> to testakis after that. klist shows testakis' ticket this time, but I am not 
> allowed to access (rwx) tetakis' files/folders, and I still have full control 
> over mamalos' files and folders.
>
> In order to be able to do something as testakis, I have to unmount the share 
> and remount it while having testakis' ticket (or having no ticket at all, and 
> giving kinit testakis after mounting the share).
>

Actually, logging in as "testakis" should allow that user to access the
mount as "testakis" once kinit'd as "testakis". The trick is that the
credential cache entry needs to be in /tmp/krb5cc_N (where 'N' is the
uid assigned to "testakis"). Same would apply to "mamalos" if that
user were logged in with a non-0 uid.

> I am not an NFS expert, but I suppose that this behavior is not the one to be 
> expected, except if I am missing some fundamental information about 
> kerberized NFS that explains it. Even so, it would be quite unwise to behave 
> so, since even if the users kdestroys their tickets, they have still all 
> permissions as when they obtained their ticket.
>

Yes, as noted above, I believe that "kdestroy" should get rid of the
Kerberized NFS "handles" for the corresponding "uid". It's on my
"to discuss with dfr and maybe do" list, but unfortunately not near
the top of it. (I'd also like to come up with a good way to do
initiator credentials from a keytab entry. The experimental patch
is considered unacceptable for FreeBSD-current etc.)

Hope that clarifies things, rick