From owner-freebsd-current@FreeBSD.ORG Fri Feb 5 14:47:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCB9A1065697 for ; Fri, 5 Feb 2010 14:47:05 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE6B8FC23 for ; Fri, 5 Feb 2010 14:47:04 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o15El30i057687 for ; Fri, 5 Feb 2010 16:47:03 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B6C2F62.8070404@eng.auth.gr> Date: Fri, 05 Feb 2010 16:46:58 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kerberized NFSv3 incorrect behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 14:47:06 -0000 Dear all, I sent this same email to freebsd-stable list as well, but I maybe had to sent it to -CURRENT since NFSv4 under fbsd is still experimental, and hence under development (and thus nvsv3-gssapi as well -I assumed-). If my assumption is wrong, please excuse me and discard this email. 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 with gssapi support. 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: nfs server: /etc/rc.conf: rpcbind_enable="YES" mountd_flags="-e" nfs_server_enable="YES" nfs_client_enable="YES" gssd_enable="YES" and the kernel is compiled with: options KGSSAPI device crypto my /etc/exports contains: /exports -alldirs -sec=krb5 nfs client: /etc/rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" gssd_enable="YES" on both client and server the /etc/krb5.conf contains: [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com kpasswd_server = kdc.example.com } [domain_realm] kdc.example.com = EXAMPLE.COM .kdc.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM 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. 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: # 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 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 obtained testakis' ticket (or having no ticket at all, and giving kinit testakis after mounting the share). 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 (or if the ticket has expired), they will still have all permissions as when they obtained their ticket. Thank you all in advance, looking forward to an answer, kind regards, mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379