From tim.haley@sun.com Mon Dec 21 14:31:36 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBLMVaO6023772 for ; Mon, 21 Dec 2009 14:31:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLMVYKm015345; Mon, 21 Dec 2009 16:31:35 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV000007X8MWP00@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 14:31:34 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV000B35X8L01C0@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 14:31:34 -0800 (PST) Received: from spidey.local (spidey.Central.Sun.COM [172.20.25.27]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nBLMVXo5046581; Mon, 21 Dec 2009 15:31:33 -0700 (MST) Received: from spidey.local (localhost [127.0.0.1]) by spidey.local (8.14.3+Sun/8.14.3) with ESMTP id nBLMO3pi001947; Mon, 21 Dec 2009 15:24:03 -0700 (MST) Received: (from timh@localhost) by spidey.local (8.14.3+Sun/8.14.3/Submit) id nBLMO3nD001946; Mon, 21 Dec 2009 15:24:03 -0700 (MST) Date: Mon, 21 Dec 2009 15:24:03 -0700 (MST) From: Tim Haley Subject: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] To: PSARC-ext@sun.com Cc: Mark.Shellenbaum@sun.com, nfs-eng@sun.com, Sam.Falkner@sun.com Message-id: <200912212224.nBLMO3nD001946@spidey.local> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7590 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@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 From Darren.Moffat@Sun.COM Mon Dec 21 14:35:08 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBLMZ8we023832 for ; Mon, 21 Dec 2009 14:35:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLMZ3Zn017022; Mon, 21 Dec 2009 16:35:07 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV000I0JXEINH00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 21 Dec 2009 14:35:06 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV0006C8XEGVD40@nwk-avmta-1.sfbay.Sun.COM>; Mon, 21 Dec 2009 14:35:05 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBLMZ4LP003845; Mon, 21 Dec 2009 22:35:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV000D00X6B4800@fe-emea-09.sun.com>; Mon, 21 Dec 2009 22:34:42 +0000 (GMT) Received: from [192.168.2.108] (99-52-200-208.lightspeed.snjsca.sbcglobal.net [99.52.200.208]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV00056YXDHBD60@fe-emea-09.sun.com>; Mon, 21 Dec 2009 22:34:33 +0000 (GMT) Date: Mon, 21 Dec 2009 14:32:11 -0800 From: Darren J Moffat Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <200912212224.nBLMO3nD001946@spidey.local> Sender: Darren.Moffat@Sun.COM To: Tim Haley Cc: PSARC-ext@Sun.COM, Mark.Shellenbaum@Sun.COM, nfs-eng@Sun.COM, Sam.Falkner@Sun.COM Message-id: <4B2FF76B.7040808@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 254 While I think it is unfortunate we need yet another special uid/gid for this it seems like the only workable solution (I'd already discussed this offline with the project team). So I'm happy to given this case a +1 as specified. -- Darren J Moffat From bart.smaalders@sun.com Mon Dec 21 14:59:32 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBLMxWFc024285 for ; Mon, 21 Dec 2009 14:59:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLMxVca000599; Mon, 21 Dec 2009 16:59:31 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV000H09YJ76A00@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 15:59:31 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV000DL9YJ2AC70@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 15:59:27 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBLMvoss006082; Mon, 21 Dec 2009 22:57:50 +0000 (GMT) Date: Mon, 21 Dec 2009 14:57:25 -0800 From: Bart Smaalders Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <200912212224.nBLMO3nD001946@spidey.local> To: Tim Haley Cc: PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Message-id: <4B2FFD55.8090109@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 617 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. > Do the client and server exchange the unknown user id numerically or via a string? If a string, does fixing the userid matter, or is it the name that's important? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Nicolas.Williams@sun.com Mon Dec 21 15:19:56 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBLNJu6u024480 for ; Mon, 21 Dec 2009 15:19:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLNJtxr016763; Mon, 21 Dec 2009 15:19:55 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV000J05ZH7A600@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 16:19:55 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV000DLWZH6ACB0@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 16:19:54 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBLNJssN010553; Mon, 21 Dec 2009 17:19:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBLNJs3W010552; Mon, 21 Dec 2009 17:19:54 -0600 (CST) Date: Mon, 21 Dec 2009 17:19:54 -0600 From: Nicolas Williams Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <4B2FFD55.8090109@Sun.COM> To: Bart Smaalders Cc: Tim Haley , PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Message-id: <20091221231954.GT1516@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B2FFD55.8090109@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1394 On Mon, Dec 21, 2009 at 02:57:25PM -0800, Bart Smaalders wrote: > 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. > > > > Do the client and server exchange the unknown user id numerically or > via a string? If a string, does fixing the userid matter, or is it the > name that's important? I expect the answer to be "a string" in the NFSv4 case, qualified with the sender's default domain (it has to have a domain qualifier). Questions: - What about NFSv3? Will the NFSv3 server reject SETATTRs that refer to UID/GID 96? Will the client send them? - The proposal says: |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. Will the NFS server ever send unknown@? If not, why not? Does the server enforce that unknown cannot be set by a client, or does only the client enforce this? If the server enforces this, does it match unknown@* or just unknown@? If the server matches unknown@*, should this be standardized? Thanks, Nico -- From Lisa.Week@Sun.COM Mon Dec 21 16:34:22 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBM0YMH5025358 for ; Mon, 21 Dec 2009 16:34:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBM0YMi8059815; Mon, 21 Dec 2009 17:34:22 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV1009052X95600@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 16:34:21 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV1005AM2X98H30@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 16:34:21 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBM0YLMI008406; Tue, 22 Dec 2009 00:34:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV100F002RK6600@mail-amer.sun.com>; Mon, 21 Dec 2009 17:34:21 -0700 (MST) Received: from dhcp-ubrm05-242-207.Central.Sun.COM ([unknown] [129.147.242.207]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV10088Y2X8HI30@mail-amer.sun.com>; Mon, 21 Dec 2009 17:34:20 -0700 (MST) Date: Mon, 21 Dec 2009 17:34:21 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <4B2FFD55.8090109@Sun.COM> Sender: Lisa.Week@Sun.COM To: Bart Smaalders Cc: Tim Haley , PSARC-ext@Sun.COM, Sam.Falkner@Sun.COM, nfs-eng@Sun.COM, Mark.Shellenbaum@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B2FFD55.8090109@Sun.COM> Status: RO Content-Length: 947 On Dec 21, 2009, at 3:57 PM, Bart Smaalders wrote: > 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. > > Do the client and server exchange the unknown user id numerically or > via a string? If a string, does fixing the userid matter, or is it > the > name that's important? With NFSv4 the unknown user is exchanged via a string. You will see the user go over the wire looking something like "unknown@sun.com". (Of course, the Solaris NFSv4 client won't send this user over the wire.) Giving "unknown" a userid matters when it comes to the rest of the stack. For example, the ACL structures (ace_t and aclent_t) use uid_t's to distinguish the users and groups in the ACL. Thanks, Lisa From bart.smaalders@sun.com Mon Dec 21 17:46:37 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBM1kbCN026063 for ; Mon, 21 Dec 2009 17:46:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBM1kaDt001173; Mon, 21 Dec 2009 17:46:36 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV100C0569O1G00@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 18:46:36 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV1000QF69NDE50@brm-avmta-1.central.sun.com>; Mon, 21 Dec 2009 18:46:35 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBM1ixr0007739; Tue, 22 Dec 2009 01:44:59 +0000 (GMT) Date: Mon, 21 Dec 2009 17:44:32 -0800 From: Bart Smaalders Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: To: Lisa Week Cc: Tim Haley , PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Message-id: <4B302480.6060007@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B2FFD55.8090109@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 1301 Lisa Week wrote: > > On Dec 21, 2009, at 3:57 PM, Bart Smaalders wrote: > >> 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. >> >> Do the client and server exchange the unknown user id numerically or >> via a string? If a string, does fixing the userid matter, or is it the >> name that's important? > > With NFSv4 the unknown user is exchanged via a string. You will see the > user go over the wire looking something like "unknown@sun.com". (Of > course, the Solaris NFSv4 client won't send this user over the wire.) > > Giving "unknown" a userid matters when it comes to the rest of the > stack. For example, the ACL structures (ace_t and aclent_t) use uid_t's > to distinguish the users and groups in the ACL. > > Thanks, > Lisa > > I would expect this to mean that the local uid doesn't matter in that case, right? Or are we hardcoding the proposed number in the kernel? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Lisa.Week@sun.com Mon Dec 21 20:34:29 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBM4YTcl028192 for ; Mon, 21 Dec 2009 20:34:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBM4R1KP015704; Mon, 21 Dec 2009 22:34:15 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV100305E10E200@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 20:34:12 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV100572E0Z8MF0@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 20:34:12 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBM4YBPf001568; Tue, 22 Dec 2009 04:34:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV100C00DZN2200@mail-amer.sun.com>; Mon, 21 Dec 2009 21:34:11 -0700 (MST) Received: from [192.168.1.113] ([unknown] [67.174.180.77]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV1006V1E0Z6GA0@mail-amer.sun.com>; Mon, 21 Dec 2009 21:34:11 -0700 (MST) Date: Mon, 21 Dec 2009 21:34:10 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <20091221231954.GT1516@Sun.COM> Sender: Lisa.Week@sun.com To: Nicolas Williams Cc: Bart Smaalders , Tim Haley , PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Message-id: <11347E65-7083-47DC-B110-08E76D1E4535@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B2FFD55.8090109@Sun.COM> <20091221231954.GT1516@Sun.COM> Status: RO Content-Length: 2369 On Dec 21, 2009, at 4:19 PM, Nicolas Williams wrote: > On Mon, Dec 21, 2009 at 02:57:25PM -0800, Bart Smaalders wrote: >> 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. >>> >> >> Do the client and server exchange the unknown user id numerically or >> via a string? If a string, does fixing the userid matter, or is it >> the >> name that's important? > > I expect the answer to be "a string" in the NFSv4 case, qualified with > the sender's default domain (it has to have a domain qualifier). That is correct. > > > Questions: > > - What about NFSv3? Will the NFSv3 server reject SETATTRs that refer > to UID/GID 96? Will the client send them? There are no changes to NFSv3 (or NFSv2) planned. > > > - The proposal says: > > |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. > > Will the NFS server ever send unknown@? If > not, why not? The NFS server will send unknown@ only if the "unknown" uid or gid is stored in the ACL by the local file system. > > > Does the server enforce that unknown cannot be set by a client, or > does only the client enforce this? Only the client enforces this. If unknown@ actually comes over the wire, the server will accept the ACL. The reason for this is to not expose the reserved uid/gid semantics to other clients (e.g. Linux) that don't care. The only id mapping related case where the server will fail the set ACL is when a user or group in the ACL can't be mapped to a valid user or group on the server. In this case, the server will send the NFS error NFS4ERR_BADOWNER to the client. This is what the Solaris server does today. > > > If the server enforces this, does it match unknown@* or just > unknown@? > > If the server matches unknown@*, should this be standardized? > See above. The server will not enforce this. If it would, yes, unknown@* should be standardized. Thanks, Lisa From Lisa.Week@Sun.COM Mon Dec 21 20:53:11 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBM4rBtl028323 for ; Mon, 21 Dec 2009 20:53:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBM4rA9v006887; Mon, 21 Dec 2009 20:53:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV100405EWMPL00@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 20:53:10 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV1003P0EWLQM00@nwk-avmta-2.sfbay.sun.com>; Mon, 21 Dec 2009 20:53:10 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBM4r92F025357; Tue, 22 Dec 2009 04:53:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV100M00EO08V00@mail-amer.sun.com>; Mon, 21 Dec 2009 21:53:09 -0700 (MST) Received: from [192.168.1.113] ([unknown] [67.174.180.77]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV100BUBEWLX740@mail-amer.sun.com>; Mon, 21 Dec 2009 21:53:09 -0700 (MST) Date: Mon, 21 Dec 2009 21:53:08 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <4B302480.6060007@Sun.COM> Sender: Lisa.Week@Sun.COM To: Bart Smaalders Cc: Tim Haley , PSARC-ext@Sun.COM, Sam.Falkner@Sun.COM, nfs-eng@Sun.COM, Mark.Shellenbaum@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B2FFD55.8090109@Sun.COM> <4B302480.6060007@Sun.COM> Status: RO Content-Length: 1374 On Dec 21, 2009, at 6:44 PM, Bart Smaalders wrote: > Lisa Week wrote: >> On Dec 21, 2009, at 3:57 PM, Bart Smaalders wrote: >>> 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. >>> >>> Do the client and server exchange the unknown user id numerically or >>> via a string? If a string, does fixing the userid matter, or is >>> it the >>> name that's important? >> With NFSv4 the unknown user is exchanged via a string. You will >> see the user go over the wire looking something like >> "unknown@sun.com". (Of course, the Solaris NFSv4 client won't send >> this user over the wire.) >> Giving "unknown" a userid matters when it comes to the rest of the >> stack. For example, the ACL structures (ace_t and aclent_t) use >> uid_t's to distinguish the users and groups in the ACL. >> Thanks, >> Lisa > > I would expect this to mean that the local uid doesn't matter in > that case, right? Or are we hardcoding the proposed number in > the kernel? [UID | GID]_UNKNOWN will be defined in usr/src/uts/common/sys/param.h (like what is done for [UID | GID]_NOBODY) and NFS will use this. Thanks, Lisa From John.Fischer@sun.com Tue Dec 22 09:28:24 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMHSOdU023668 for ; Tue, 22 Dec 2009 09:28:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBMHSNAJ064597; Tue, 22 Dec 2009 10:28:24 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV200I29DVBSW00@brm-avmta-1.central.sun.com>; Tue, 22 Dec 2009 10:28:23 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200CQNDVB3K60@brm-avmta-1.central.sun.com>; Tue, 22 Dec 2009 10:28:23 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMHSMXJ003478; Tue, 22 Dec 2009 17:28:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200A00CN7LN00@mail-amer.sun.com>; Tue, 22 Dec 2009 10:28:22 -0700 (MST) Received: from [192.168.0.101] ([unknown] [76.20.56.122]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV200AQBDURLP60@mail-amer.sun.com>; Tue, 22 Dec 2009 10:28:04 -0700 (MST) Date: Tue, 22 Dec 2009 09:27:55 -0800 From: John Fischer Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <200912212224.nBLMO3nD001946@spidey.local> Sender: John.Fischer@sun.com To: Tim Haley Cc: PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Reply-to: John.Fischer@sun.com Message-id: <4B31019B.3060006@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 8228 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@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@opensolaris.org From Lisa.Week@sun.com Tue Dec 22 13:30:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMLUE7g028064 for ; Tue, 22 Dec 2009 13:30:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBMLU6eT048779; Tue, 22 Dec 2009 14:30:13 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV200J01P2CMT00@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Dec 2009 13:30:12 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200FMUP2CHK80@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Dec 2009 13:30:12 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMLUBLX028278; Tue, 22 Dec 2009 21:30:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200700OVYP000@mail-amer.sun.com>; Tue, 22 Dec 2009 14:30:11 -0700 (MST) Received: from dhcp-ubrm05-243-12.Central.Sun.COM ([unknown] [129.147.243.12]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV20047LP29GDE0@mail-amer.sun.com>; Tue, 22 Dec 2009 14:30:09 -0700 (MST) Date: Tue, 22 Dec 2009 14:30:08 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <4B31019B.3060006@sun.com> Sender: Lisa.Week@sun.com To: John.Fischer@sun.com Cc: Tim Haley , Sam.Falkner@sun.com, PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, nfs-eng@sun.com Message-id: <0804C565-B330-4C33-AE19-826F652425CC@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B31019B.3060006@sun.com> Status: RO Content-Length: 8560 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@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@opensolaris.org > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From John.Fischer@sun.com Tue Dec 22 13:49:13 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMLnD3J028163 for ; Tue, 22 Dec 2009 13:49:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBMLnDaP022746; Tue, 22 Dec 2009 13:49:13 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV200L03PY1Q900@brm-avmta-1.central.sun.com>; Tue, 22 Dec 2009 14:49:13 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200K1RPY11310@brm-avmta-1.central.sun.com>; Tue, 22 Dec 2009 14:49:13 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMLnCg4005423; Tue, 22 Dec 2009 21:49:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200C00PX5K200@mail-amer.sun.com>; Tue, 22 Dec 2009 14:49:12 -0700 (MST) Received: from [192.168.10.7] ([unknown] [76.20.56.122]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV200JJMPXS9Y40@mail-amer.sun.com>; Tue, 22 Dec 2009 14:49:05 -0700 (MST) Date: Tue, 22 Dec 2009 13:48:56 -0800 From: John Fischer Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <0804C565-B330-4C33-AE19-826F652425CC@sun.com> Sender: John.Fischer@sun.com To: Lisa Week Cc: Tim Haley , Sam.Falkner@sun.com, PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, nfs-eng@sun.com Reply-to: John.Fischer@sun.com Message-id: <4B313EC8.6010208@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B31019B.3060006@sun.com> <0804C565-B330-4C33-AE19-826F652425CC@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 8824 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@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@opensolaris.org >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > From Lisa.Week@sun.com Tue Dec 22 14:11:26 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMMBQjg028874 for ; Tue, 22 Dec 2009 14:11:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBMMBOgI025192; Tue, 22 Dec 2009 16:11:26 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV20081HQZ1OD00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Dec 2009 14:11:25 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV2004QYQYYUZD0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Dec 2009 14:11:23 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMMBMBc019966; Tue, 22 Dec 2009 22:11:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200400QL39A00@mail-amer.sun.com>; Tue, 22 Dec 2009 15:11:22 -0700 (MST) Received: from dhcp-ubrm05-243-12.Central.Sun.COM ([unknown] [129.147.243.12]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV200GI9QYICC50@mail-amer.sun.com>; Tue, 22 Dec 2009 15:11:06 -0700 (MST) Date: Tue, 22 Dec 2009 15:11:05 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <4B313EC8.6010208@sun.com> Sender: Lisa.Week@sun.com To: John.Fischer@sun.com Cc: Tim Haley , Sam.Falkner@sun.com, PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, nfs-eng@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> <4B31019B.3060006@sun.com> <0804C565-B330-4C33-AE19-826F652425CC@sun.com> <4B313EC8.6010208@sun.com> Status: RO Content-Length: 9634 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@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@opensolaris.org >>> _______________________________________________ >>> opensolaris-arc mailing list >>> opensolaris-arc@opensolaris.org From gww@sac.sfbay.sun.com Mon Jan 4 16:37:04 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o050b4Qc004778 for ; Mon, 4 Jan 2010 16:37:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o050b1Uu027141; Mon, 4 Jan 2010 16:37:03 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVR00G0D0DR4E00@brm-avmta-1.central.sun.com>; Mon, 04 Jan 2010 17:37:03 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVR00DWS0DQO8C0@brm-avmta-1.central.sun.com>; Mon, 04 Jan 2010 17:37:02 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o050b0FN015612; Mon, 04 Jan 2010 16:37:00 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o050b09J004775; Mon, 04 Jan 2010 16:37:00 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o050b0aY004774; Mon, 04 Jan 2010 16:37:00 -0800 (PST) Date: Mon, 04 Jan 2010 16:37:00 -0800 (PST) From: Gary Winiger Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] To: Darren.Moffat@sun.com, Tim.Haley@sun.com Cc: Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Sam.Falkner@sun.com, nfs-eng@sun.com Message-id: <201001050037.o050b0aY004774@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 727 Darren writes: > While I think it is unfortunate we need yet another special uid/gid for > this it seems like the only workable solution (I'd already discussed > this offline with the project team). So I'm happy to given this case a > +1 as specified. I agree with Darren, it's unfortunate (and that nobody4 cannot be repurposed). Tim writes: > Proposed Solution: > ------------------ > > 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::::::: Why is this being proposed as a nologin account (NP) rather than a locked account (*LK*)? Why does unknown need to run jobs on the system? +1 if a locked account. Gary.. From Lisa.Week@Sun.COM Mon Jan 4 21:29:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o055TM9g008967 for ; Mon, 4 Jan 2010 21:29:22 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o055TLSA002621; Mon, 4 Jan 2010 23:29:21 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVR00L03DWXEZ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jan 2010 21:29:21 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVR000STDWXIS70@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jan 2010 21:29:21 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o055TKpp012588; Tue, 05 Jan 2010 05:29:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVR00200DNA4E00@mail-amer.sun.com>; Mon, 04 Jan 2010 22:29:20 -0700 (MST) Received: from [192.168.1.113] ([unknown] [67.174.180.77]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVR00FI1DWWLB40@mail-amer.sun.com>; Mon, 04 Jan 2010 22:29:20 -0700 (MST) Date: Mon, 04 Jan 2010 22:29:18 -0700 From: Lisa Week Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <201001050037.o050b0aY004774@sac.sfbay.sun.com> Sender: Lisa.Week@Sun.COM To: Gary Winiger Cc: Darren.Moffat@Sun.COM, Tim.Haley@Sun.COM, Sam.Falkner@Sun.COM, PSARC-ext@Sun.COM, Mark.Shellenbaum@Sun.COM, nfs-eng@Sun.COM Message-id: <93C3BC70-116B-4E9B-B2D7-03DB019B7F94@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001050037.o050b0aY004774@sac.sfbay.sun.com> Status: RO Content-Length: 981 On Jan 4, 2010, at 5:37 PM, Gary Winiger wrote: > Darren writes: > >> While I think it is unfortunate we need yet another special uid/gid >> for >> this it seems like the only workable solution (I'd already discussed >> this offline with the project team). So I'm happy to given this >> case a >> +1 as specified. > > I agree with Darren, it's unfortunate (and that nobody4 cannot > be repurposed). > > Tim writes: > >> Proposed Solution: >> ------------------ >> >> 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::::::: > > Why is this being proposed as a nologin account (NP) rather > than a locked account (*LK*)? Why does unknown need to > run jobs on the system? > > +1 if a locked account. After reviewing NP vs. *LK* again I agree that this should be a locked rather than a nologin account. unknown should not need to run jobs on the system. Thanks, Lisa From tim.haley@sun.com Wed Jan 6 14:40:44 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o06MeiAt007273 for ; Wed, 6 Jan 2010 14:40:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o06MehxJ027169; Wed, 6 Jan 2010 15:40:44 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVU0060JKBVTJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Jan 2010 14:40:43 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVU004WYKBU7810@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Jan 2010 14:40:43 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o06MegdY001017; Wed, 06 Jan 2010 22:40:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVU00K00JXO9U00@mail-amer.sun.com>; Wed, 06 Jan 2010 15:40:42 -0700 (MST) Received: from Giles.local ([unknown] [71.196.247.195]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVU00L1BKBNB430@mail-amer.sun.com>; Wed, 06 Jan 2010 15:40:35 -0700 (MST) Date: Wed, 06 Jan 2010 15:40:35 -0700 From: Tim Haley Subject: Re: Reserved uid/gid for distinguishing unmappable users/groups in NFSv4 ACLs [PSARC/2009/683 FastTrack timeout 01/06/2010] In-reply-to: <200912212224.nBLMO3nD001946@spidey.local> Sender: Timothy.Haley@sun.com To: PSARC-ext@sun.com Cc: Sam.Falkner@sun.com, nfs-eng@sun.com, Mark.Shellenbaum@sun.com Message-id: <4B451163.1080905@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912212224.nBLMO3nD001946@spidey.local> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Status: RO Content-Length: 49 This case was approved in today's meeting. -tim