From: Benny Halevy (benny_halevy@yahoo.com)
Date: 08/03/02-09:14:51 PM Z
Message-ID: <20020804021451.9441.qmail@web14106.mail.yahoo.com>
Date: Sat, 3 Aug 2002 19:14:51 -0700 (PDT)
From: Benny Halevy <benny_halevy@yahoo.com>
Subject: Re: new ACL text
Mike,
As I read it, the text is still not clear about the
issue of having both ACLs and file mode (Unix style
permissions). Currently the only reference I could
find to this subject is in Section 5.5 saying
"Unix-style permission bits for this object
(deprecated in favor of ACLs)". The issue was
discussed recently in
a thread called "Interaction between mode bits and
acls" (see
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0157.html)
yet I believe it deserves some elaboration.
If the interaction between conflicting ACE's and mode
bits is undefined and left open to the server then the
spec should say so. Recommended guidelines could be
useful too :-)
When an ACL is defined for a file, what should be the
result of local stat()/chmod() or GETATTR/SETATTR when
the file is exported also in NFSv[23]? The
interesting cases are:
ACL is defined for the file and -
a. The file has no mode attribute.
b. The file has a mode attribute.
Thanks,
Benny
--- Mike Kupfer <kupfer@athyra.eng.sun.com>
wrote:
> Here's a new draft of the ACL text. It includes
the
> formatting
> changes from the latest I-D, and it incorporates
the
> feedback I got
> from Dave Noveck. Change bars are relative to
the
> text I sent out on
> 16 July and do not include the formatting
changes.
>
> mike
>
> 5.9. Access Control Lists
>
> The NFS ACL attribute is an array of access
> control entries (ACE).
> There are various access control entry types,
as
> defined in Section
> 5.9.1. The server is able to communicate
which
> ACE types are
> supported by returning the appropriate value
> within the aclsupport
> attribute. Each ACE covers one or more
> operations on a file or
> directory as described in 5.9.2. It may also
> contain one or more
> flags that modify the symantics of the ACE as
> defiend in Section
> 5.9.3.
>
> The NFS ACE attribute is defined as follows:
>
> typedef uint32_t acetype4;
> typedef uint32_t aceflag4;
> typedef uint32_t acemask4;
>
> struct nfsace4 {
> acetype4 type;
> aceflag4 flag;
> acemask4 access_mask;
> utf8string who;
> };
>
> To determine if a request succeeds, each
nfsace4
> entry is processed |
> in order by the server. Only ACEs which have
a
> "who" that matches
> the requester are considered. Each ACE is
> processed until all of
> the bits of the requester's access have been
> ALLOWED. Once a bit
> (see below) has been ALLOWED by an
> ACCESS_ALLOWED_ACE, it is no
> longer considered in the processing of later
> ACEs. If an
> ACCESS_DENIED_ACE is encountered where the
> requester's mode still
> has unALLOWED bits in common with the
> "access_mask" of the ACE, the
> request is denied.
>
> The NFS ACL model is quite rich. Some server
> platforms may provide |
> access control functionality that goes beyond
the
> Unix-style mode
> attribute, but which is not as rich as the NFS
> ACL model. So that
> users can take advantage of this more limited
> functionality, the
> server may indicate that it supports ACLs as
long
> as it follows the |
> guidelines for mapping between its ACL model
and
> the NFS ACL model.
>
> The situation is complicated by the fact that
a
> server may have
> multiple modules that enforce ACLs. For
example,
> the enforcement
> for NFS access may be handled different from
the
> enforcement for |
> local access, and both may be different from
the
> enforcement for |
> access through other protocols such as SMB.
So
> it may be useful
> for a server to accept an ACL even if not all
of
> its modules are
> able to support it.
>
> The guiding principle in all cases is that the
> server must not |
> accept ACLs that appear to make the file more
> secure than it really
> is.
>
> 5.9.1. ACE type
>
> Type Description
>
>
_____________________________________________________
> ALLOW
> Explicitly grants the access
defined
> in
> acemask4 to the file or
directory.
>
> DENY
> Explicitly denies the access
defined
> in
> acemask4 to the file or
directory.
>
> AUDIT
> LOG (system dependent) any access
> attempt to a file or directory
which
> uses any of the access methods
> specified
> in acemask4.
>
> ALARM
> Generate a system ALARM (system
> dependent) when any access
attempt
> is
> made to a file or directory for
the
> access methods specified in
> acemask4.
>
> A server need not support all of the above ACE
> types. The bitmask
> constants used to represent the above
definitions
> within the
> aclsupport attribute are as follows:
>
> const ACL4_SUPPORT_ALLOW_ACL = 0x00000001;
> const ACL4_SUPPORT_DENY_ACL = 0x00000002;
> const ACL4_SUPPORT_AUDIT_ACL = 0x00000004;
> const ACL4_SUPPORT_ALARM_ACL = 0x00000008;
>
> The semantics of the "type" field
follow the
> descriptions provided
> above.
>
> The constants used for the type field
(acetype4)
> are as follows:
>
> const ACE4_ACCESS_ALLOWED_ACE_TYPE =
> 0x00000000;
> const ACE4_ACCESS_DENIED_ACE_TYPE =
> 0x00000001;
> const ACE4_SYSTEM_AUDIT_ACE_TYPE =
> 0x00000002;
> const ACE4_SYSTEM_ALARM_ACE_TYPE =
> 0x00000003;
>
> Clients should not attempt to set an ACE
unless
> the server claims
> support for that ACE type. If the server
> receives a request to set
> an ACE that it cannot store, it must reject
the
> request with
> NFS4ERR_ATTRNOTSUPP. |
>
> If the server receives a request to set an ACE
> that it can store
> but cannot enforce, the server SHOULD reject
the
> request. |
>
> Example: suppose a server can enforce NFS ACLs
> for NFS access but
> cannot enforce ACLs for local access. If
> arbitrary processes can
> run on the server, then the server SHOULD NOT
> indicate ACL support. |
> On the other hand, if only trusted
administrative
> programs run
> locally, then the server may indicate ACL
> support. |
>
>
> 5.9.2. ACE Access Mask
>
> The access_mask field contains values based on
> the following:
>
> Access Description
>
>
_______________________________________________________________
> READ_DATA
> Permission to read the
> data of the file
> LIST_DIRECTORY
> Permission to list the
> contents of a
> directory
> WRITE_DATA
> Permission to modify
the
> file's data
> ADD_FILE
> Permission to add a new
> file to a
> directory
> APPEND_DATA
> Permission to append
data
> to a file
> ADD_SUBDIRECTORY
> Permission to create a
> subdirectory
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:08 AM Z CST