Date: Fri, 25 May 2012 09:36:58 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> Cc: freebsd-fs@freebsd.org, dfr <dfr@freebsd.org> Subject: Re: NLM uses AUTH_SYS ignoring sec option in mount_nfs Message-ID: <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey Simonenko wrote: > Hello, > > Looks like that NLM always uses AUTH_SYS even if a client specified > another security flavor in the mount_nfs's "sec" option. Also NLM > on the server does not verify that NLM client's security flavor > is allowed by NFS exported file system, security flavors array from > VFS_CHECKEXP() is ignored in nlm/nlm_prot_impl.c:nlm_get_vfs_state(). > > Such behaviour of NLM I see on 10-CURRENT, I added log messages to > the kernel to see security flavors used by NFSv3 and NLM requests. > Both NFS client and server are on the same system, NFSv3 mounts are > from unprivileged users. > > According to [1] NLMv4 allows to use different security flavors. > > Can somebody comment such behaviour of NLM? > Well, as you might know, I wasn't the author of the NLM implementation, so I'm just commenting based on what little I know about it. (I've added dfr@ to the cc list, in case he can provide more insight?) I think the big problem with using Kerberos with the NLM is "what happens when the user's TGT ticket expires on the client?". If this happens and the server requires a valid credential based on a Kerberos ticket, then the client/user won't be able to unlock the locks that have been put on the file. It is conceivable that these file locks could hang around "forever". (An obvious case here is where the user for a uid isn't actually prsent to do a fresh kinit when the TGT expires. Another is an application program that doesn't handle a EACCES error from a lock syscall well.) I think this problem could be avoided by allowing AUTH_SYS for unlock operations, so that the unlocking won't fail. Also, from a glance at the code, it appears that the client will re-acquire locks after a server crashes/reboots. What do you do if this re-acquisition fails, due to a TGT timeout? NFSv4 works around the above issues by using a "host based initiator credential in a keytab file" for system stuff like lock recovery. (The FreeBSD client will fall back to using this "system credential" for LockU operations, if the user's credential fails, but I don't know if all clients choose to do this? Grep in the client sources for ND_USEGSSNAME to see this being used.) Unfortunately, the patch I have to add support for "host based initiator credentials in the keytab file" is ugly and has never made it into head. Maybe I'll figure out a way to resolve this before the end of this summer? Hopefully dfr@ can provide some more insight, but my feeling is that making the NLM server require Kerberos credentials might result in more serious problems than the security risk of not requiring them. I'm sure I've stated it before (and, yes, I am biased), but if you want reliable byte range locking to work across multiple clients, then using NFSv4 is a much better bet than the NLM. rick > [1] http://pubs.opengroup.org/onlinepubs/9629799/chap14.htm > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?169170676.853090.1337953018295.JavaMail.root>