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> _______________________________________________
>
[hidden email] mailing list
>
http://lists.freebsd.org/mailman/listinfo/freebsd-fs> To unsubscribe, send any mail to "
[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fsTo unsubscribe, send any mail to "
[hidden email]"
Locked
