Rick Macklem wrote:
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: 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
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
_______________________________________________
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"
Rick,
thank you for all your answers. I am planning on setting up the computer
labs of my department using kerberized nfsv3 (since v4 seems to be
"more" experimental) with a FreeBSD nfs server and Linux nfs clients. I
was wondering "how stable" such an implementation would be; meaning that
I wouldn't want to end up with an unstsable setup when receiving
requests from 50-60 simultaneous clients, because that would be my
everyday scenario.
Thanks again for all your explanations (you covered me fully) and for
your understanding of my remarks.
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"
