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
