Hi John, On Dec 22, 2009, at 2:48 PM, John Fischer wrote:
> > Let me ask a different way.... Should Nautilus be modified > to take advantage of the new interface? > Sorry, but your question is still confusing to me because in my understanding Nautilus doesn't (currently) support NFSv4/ZFS ACLs at all. I understand that it did at one point, but it does not now. Please correct me if I am wrong. Regardless, if Nautilus did/does support NFSv4/ZFS ACLs, there would be no modifications needed for Nautilus to take advantage of this proposal. Thanks, Lisa > > 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
