Lisa, How will this impact desktop components like Nautilus? Does there need to be a corresponding update?
Thanks, John Tim Haley wrote: > I am sponsoring the following fast-track for Lisa Week. It introduces > a new reserved uid and gid for purposes of improved ACL manipulation > when an id is not mappable by the client or server. Requested binding > is patch/micro. Timeout is 1/6/2010. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 > ACLs > 1.2. Name of Document Author/Supplier: > Author: Lisa Week > 1.3 Date of This Document: > 21 December, 2009 > > 4. Technical Description > > When Access Control Lists (ACLs) are sent over the wire in NFSv4 the > users and groups in the Access Control Entries (ACEs) are in the form > of UTF-8 strings. nfsmapid(1M) is responsible for translating or mapping > these strings into valid users and groups on the client and server. > > If there are entries in the ACL that cannot be mapped to valid users > or groups we run into the two type of problems: > > Case 1: Upon doing a get ACL operation, the server may send the client > an ACL with a user or group that the client does not know > about. > > Case 2: Upon doing a set ACL operation, the client may > send the server an ACL with a user or group that the server > does not know about. > > Currently, the NFSv4 implementation will fail the operations in both > Case 1 and 2. Case 2 remains valid (i.e. it is appropriate to fail > the set ACL operation), but Case 1 has proven to be confusing to users > as it causes simple operations such as "ls -l" and "ls -l[V|v]" to > fail with "Permission denied". > > > Proposed Solution: > ------------------ > > This case proposes a new reserved uid and gid in the vendor range > (0-99) that the NFSv4 client and server will use to designate that an > unmappable user or group has been detected in the ACE of an ACL. This > reserved uid and gid will be installed in /etc/passwd (also > /etc/shadow) and /etc/group, respectively. > > The /etc/passwd entry will be as follows: > unknown:x:96:96:Unknown Remote UID:/: > > The /etc/shadow entry will be as follows: > unknown:NP::::::: > > The /etc/group entry will be as follows: > unknown::96: > > The client will map users or groups in an ACL that are unmappable to > this newly reserved uid/gid. This reserved uid/gid will not be allowed > to be set in an ACL from the Solaris NFSv4 client. > > Example: > > For this example, we will assume we have the following ACL set on a > file at the server: > > (nfs-server:/export):37 % ls -lV aclfile > -rw-r--r--+ 1 lisagab staff 0 Nov 25 16:47 aclfile > user:junkuser:rwx-----------:-------:deny > owner@:--x-----------:-------:deny > owner@:rw-p---A-W-Co-:-------:allow > group@:-wxp----------:-------:deny > group@:r-------------:-------:allow > everyone@:-wxp---A-W-Co-:-------:deny > everyone@:r-----a-R-c--s:-------:allow > > (Note: "junkuser" is a user that is not mappable to a valid user on > the NFSv4 client.) > > Behavior before the fix: > ------------------------------- > > The end user on the NFSv4 client saw a simple "ls -lV" failing: > (old-nfs-client:/mnt):6 % df /mnt > Filesystem kbytes used avail capacity Mounted on > nfs-server:/export 57621265 23 57621242 1% /mnt > (old-nfs-client:/mnt):11 % ls -lV aclfile > ls: can't read ACL on aclfile: Permission denied > -rw-r--r-- 1 lisagab staff 0 Dec 16 17:31 aclfile > > Behavior after the fix: > ---------------------------- > > The end user on the NFSv4 client will see: > > (new-nfs-client:/mnt):21 % ls -lV aclfile > -rw-r--r--+ 1 lisagab staff 0 Nov 25 16:47 aclfile > user:unknown:rwx-----------:-------:deny > owner@:--x-----------:-------:deny > owner@:rw-p---A-W-Co-:-------:allow > group@:-wxp----------:-------:deny > group@:r-------------:-------:allow > everyone@:-wxp---A-W-Co-:-------:deny > everyone@:r-----a-R-c--s:-------:allow > > If an end user tries to do a read, modify, write ACL operation on the > NFSv4 client on an ACL with an unmappable user/group they will see: > > (new-nfs-client:/mnt):22 % chmod A+user:lisagab:rwx:allow aclfile > chmod: ERROR: Failed to set ACL: Permission denied > > If a user tries to do a NON-read,modify,write ACL operation on the > NFSv4 client, everything works as expected (because the unknown user > is not in the ACL): > > (new-nfs-client:/mnt):26 % chmod A=user:lisagab:rwx:allow aclfile > (new-nfs-client:/mnt):27 % ls -lV > total 4 ----------+ 1 lisagab staff 0 Nov 25 16:47 aclfile > user:lisagab:rwx-----------:-------:allow > > Alternative solutions considered: > -------------------------------------------- > > 1. Repurposing "nobody4" user rather than reserving a new user: > > The "nobody4" user is the anonymous user account that is the SunOS 4.X > software version of the "nobody" account. As a reminder, the "nobody" > account secures NFS resources. When a user is logged in as root on an > NFS client and attempts to access a remote file resource, the UID > number changes from 0 to the UID of nobody (60001). > > There are no major technical problems behind reusing nobody4, the main > problems revolve around documentation and the current user base's > understanding of what this user/group is for. There would be a large > amount of documentation updates needed in order to repurpose nobody4 > from the SunOS 4.X anonymous account to the new "Unknown Remote UID". > Of course, we also have to update documentation for adding a new > user/group, but there is no risk assumed. Risk is introduced when we > consider all of the external documentation sites that have information > about nobody4 documented. We do not control these sites and expect > that we will introduce customer confusion if we repurpose. > > A good example is: there are external documentation sites out there > that advise users to get rid of the "nobody4" account as it is > unneeded. How can we make sure that we change this practice? It > seems like it may be close to impossible. > > E.g. > http://www.accs.com/p_and_p/SolSec/clean.html > http://www.mail-archive.com/focus-sun at securityfocus.com/msg00067.html > http://www.gotroot.com/tiki-index.php?page=Solaris+Hardening+Guide > > 2. Reusing "noaccess" user/ group rather than reserving a new user/group: > > The "noaccess" user/group is an account assigned to a user/group or a > process that needs access to a system through some application without > actually logging into the system. > > Reusing this account would introduce the side effect that users cannot > set ACLs with the noaccess user or group in ACLs over NFS. They would > still be able to do this on local file systems, but not on NFS. This > leaves NFS at a disadvantage and since the noaccess user/group already > has well defined semantics, it is deemed not suitable for this > purpose. > > > Man page changes: > -------------------------- > > The new reserved user and group will be documented in the appropriate > man pages and system administration guides. Documentation addendum is > as shown below: > > To documentation associated with the default passwd file contents: > > User Name User ID Description > unknown 96 Account reserved for unmappable users in NFSv4 ACLs > > Those documentation with the default group file contents > > User Name Group ID Description > unknown 96 Account reserved for unmappable groups in NFSv4 > ACLs > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
