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@EXAMPLE.COM
>
> Issued Expires Principal
> Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/EXAPMLE.COM@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