On Dec 22, 2009, at 10:27 AM, John Fischer wrote: > Lisa, > > How will this impact desktop components like Nautilus? > Does there need to be a corresponding update? >
As far as I can tell, this will not affect Nautilus. Thanks, Lisa > > 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 > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
