>Number: 169680 >Category: kern >Synopsis: NLM and security flavors >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 06 09:50:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Andrey Simonenko >Release: FreeBSD 10.0-CURRENT amd64 >Organization: >Environment: >Description:
NLM on a client system always uses AUTH_SYS even if a client specified another security flavor in the mount_nfs's "sec" option. NLM on a server system 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(). I added log messages to the kernel to see security flavors used by NFSv3 and NLM requests to verify such behaviour. Both NFS client and server are on the same system, NFSv3 mounts are from unprivileged users. Current implementation of 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 user credentials do not correspond to remote user credentials mapping shows that fcntl(F_SETLK) returns EACCES. According to [1] NLMv4 allows to use different security flavors. [1] http://pubs.opengroup.org/onlinepubs/9629799/chap14.htm >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
