[Acl-Devel] NFS ACL support...

[Andreas Gruenbacher]

On Thu, 16 Nov 2000, Dominik Kubla wrote:

> On Thu, Nov 16, 2000 at 10:08:14AM +0100, Andreas Gruenbacher wrote:
> > 
> > Note that NFSv2 can't support ACLs at all, as clients make access control
> > decisions based on the file mode permission bits. NFSv3 works because it
> > uses an RPC to check whether access is granted.
> 
> Sun definitely does ACL over NFSv2, also the docs state that the ACL layer
> is "bypassed" (whatever that means) if a client does not request the
> extension.

I don't know how they do it. Probably they do full ACL access control
decisions on the client. The problem I see is that non-ACL-aware NFSv2
clients do access control decisions based on the file mode permission
bits, so the only way to make them work without breaking file security is
to send them a stripped-down mode parameter. On the other hand, such a
stripped-down mode parameter would be wrong for ACL aware clients.

This is from the Tru64 acl(4) manual page:

[] NFS Flatten Mode
[]
[] The NFS flatten mode (nfs_flatten_mode) attribute in the [] "sec"
[] subsystem controls the permission bits of a file or directory with
[] an access ACL as seen by an NFS V2 client.  The sysconfigdb command
[] should be used to set this attribute in the /etc/sysconfigtab file.
[]
[] NFS V2 clients make their own access decisions based on their
[] interpretation of a file's permission bits.  Based on this decision,
[] they may allow access to data cached on the client from a previous
[] access by another user.  A file that is protected by an access ACL
[] cannot reflect the correct access for all users in the permission bits
[] for the file.  It may be that access that would be granted by the
[] permission bits is actually denied explicitly by the access ACL.  It
[] may also be that access that seems to be denied by the permission bits
[] is, in fact, granted explicitly by the access ACL.  The nfs-flatten-
[] mode parameter can be used to modify the permission bits that exist on
[] the server before presentation to the client.
[]
[] NFS V3 clients have, in essence, an "open" protocol request that they
[] use to defer the access decision to the server, and grants access only
[] when they have previously made an "open" request for the same user
[] and file.
[]
[] Setting the nfs-flatten-mode parameter to the restrictive setting
[] (1) can cause some users to be denied access to files that they should
[] legitimately be granted access to.  Setting the parameter to the
[] permissive setting (2) can cause some users to be granted access to
[] files that they should not be granted access to, but only for read
[] access to data in the client cache, since any request that is sent to
[] the server (and all write requests are supposed to be sent to the
[] server) results in an access decision on the server denying the
[] request.  Setting the parameter to the unmodified setting (0) leaves
[] the permission bits unmodified, possibly resulting in both inadvertent
[] denial and granting of access, while accurately displaying the
[] permission bits on the client as they would be displayed on the server.
[]
[] The allowable values are:
[]
[]  0 - unmodified
[]       The actual file permission bits are sent.
[]
[]  1 - restrictive
[]       The owning group and other fields of the file permission bits are
[]       modified such that only access that would be granted to everyone
[]       in the ACL is granted by the permission bits.
[]
[]  2 - permissive
[]       The owning group and other fields of the file permission bits are
[]       modified such that access that is granted to anyone in the ACL is
[]       granted by the permission bits.
[]
[]  The default value is 0.

I have only implemented a restrictive form in the kernel patch as other
approaches don't preserve file security. The mode parameter is modified
such that the user and group file mode permission bits reflect the
effective permissions of the ACL_USER_OBJ and ACL_GROUP_OBJ ACL entries.
The world file mode permission bits reflect the minimum permissions
granted to other users. Here's an example, constructed to show all those
cases:

---------------------------------------------------------------------
ag at jessie:/acl > getfacl mask
# file: mask
# owner: ag
# group: users
user::rw-
user:lisa:rwx                   #effective:rw-
user:joe:---
group::r-x                      #effective:r--
mask:rw-
other:rw-

ag at jessie:/acl > ls -l mask
-rw-rw-rw-+   1 ag       users           0 Nov 16 01:33 mask
ag at jessie:/acl > mount localhost:/acl/ /mnt/
ag at jessie:/acl > cd /mnt/
ag at jessie:/acl > ls -l mask
-rw-r-----    1 ag       users           0 Nov 16 01:33 mask
---------------------------------------------------------------------

Dominik, as that behavior is nowhere documented, are you able to test
which file mode permission bits Solaris presents to ACL aware + ACL
unaware NFSv2 clients?


Thanks,
Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message