Date: Sat, 26 May 2012 15:42:16 +0300 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org, dfr <dfr@freebsd.org> Subject: Re: NLM uses AUTH_SYS ignoring sec option in mount_nfs Message-ID: <20120526124216.GA1302@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> References: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.ua> <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 25, 2012 at 09:36:58AM -0400, Rick Macklem wrote: > 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? If such approach is used, then NLM will work only in cases when user credentials on a client system correspond to user credentials on a server system. When a user kinit'ed, then corresponding user's credentials are setup by the server for all NFS RPC requests. When a user opened a file, then is trying to lock it, user's credentials are passed in RPC request (because of AUTH_SYS in NLM) and a server will use them to verify whether a user is allowed to access a file that is being locked. Simple check when local credentials do not correspond to remote user credentials mapping shows that fcntl(F_SETLK) returns EACCES.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120526124216.GA1302>