Lisa, Let me ask a different way.... Should Nautilus be modified to take advantage of the new interface?
Thanks, John Lisa Week wrote: > > 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 >
