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:
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: mama...@example.com
Issued Expires Principal
Feb 5 11:20:49 Feb 5 21:20:47 krbtgt/exapmle....@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 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, they have
still 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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
