From owner-freebsd-stable@FreeBSD.ORG Fri Feb 5 17:30:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9C7106577C for ; Fri, 5 Feb 2010 17:30:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C43E48FC0C for ; Fri, 5 Feb 2010 17:29:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN7ka0uDaFvG/2dsb2JhbADYOYRSBA X-IronPort-AV: E=Sophos;i="4.49,414,1262581200"; d="scan'208";a="64395496" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 05 Feb 2010 12:29:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 990DE210138; Fri, 5 Feb 2010 12:29:54 -0500 (EST) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwb1cWR9X0uI; Fri, 5 Feb 2010 12:29:52 -0500 (EST) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id B69D82100FB; Fri, 5 Feb 2010 12:29:52 -0500 (EST) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o15Hf0029809; Fri, 5 Feb 2010 12:41:01 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Feb 2010 12:41:00 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: George Mamalakis In-Reply-To: <4B6BE7A2.6000402@eng.auth.gr> Message-ID: References: <4B6BE7A2.6000402@eng.auth.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable Subject: Re: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 17:30:00 -0000 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