待翻譯。
6.4.3. Creating New Objects
If a server supports any ACL attributes, it may use the ACL
attributes on the parent directory to compute an initial ACL
attribute for a newly created object. This will be referred to as
the inherited ACL within this section. The act of adding one or more
ACEs to the inherited ACL that are based upon ACEs in the parent
directory’s ACL will be referred to as inheriting an ACE within this
section.
Implementors should standardize what the behavior of CREATE and OPEN
must be depending on the presence or absence of the mode and ACL
attributes.
1. If just the mode is given in the call:
In this case, inheritance SHOULD take place, but the mode MUST be
applied to the inherited ACL as described in Section 6.4.1.1,
thereby modifying the ACL.
2. If just the ACL is given in the call:
In this case, inheritance SHOULD NOT take place, and the ACL as
defined in the CREATE or OPEN will be set without modification,
and the mode modified as in Section 6.4.1.2.
3. If both mode and ACL are given in the call:
In this case, inheritance SHOULD NOT take place, and both
attributes will be set as described in Section 6.4.1.3.
Shepler, et al. Standards Track [Page 149]RFC 5661 NFSv4.1 January 2010
4. If neither mode nor ACL is given in the call:
In the case where an object is being created without any initial
attributes at all, e.g., an OPEN operation with an opentype4 of
OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD
NOT take place (note that EXCLUSIVE4_1 is a better choice of
createmode4, since it does permit initial attributes). Instead,
the server SHOULD set permissions to deny all access to the newly
created object. It is expected that the appropriate client will
set the desired attributes in a subsequent SETATTR operation, and
the server SHOULD allow that operation to succeed, regardless of
what permissions the object is created with. For example, an
empty ACL denies all permissions, but the server should allow the
owner’s SETATTR to succeed even though WRITE_ACL is implicitly
denied.
In other cases, inheritance SHOULD take place, and no
modifications to the ACL will happen. The mode attribute, if
supported, MUST be as computed in Section 6.3.2, with the
MODE4_SUID, MODE4_SGID, and MODE4_SVTX bits clear. If no
inheritable ACEs exist on the parent directory, the rules for
creating acl, dacl, or sacl attributes are implementation
defined. If either the dacl or sacl attribute is supported, then
the ACL4_DEFAULTED flag SHOULD be set on the newly created
attributes.
6.4.3.1. The Inherited ACL
If the object being created is not a directory, the inherited ACL
SHOULD NOT inherit ACEs from the parent directory ACL unless the
ACE4_FILE_INHERIT_FLAG is set.
If the object being created is a directory, the inherited ACL should
inherit all inheritable ACEs from the parent directory, that is,
those that have the ACE4_FILE_INHERIT_ACE or
ACE4_DIRECTORY_INHERIT_ACE flag set. If the inheritable ACE has
ACE4_FILE_INHERIT_ACE set but ACE4_DIRECTORY_INHERIT_ACE is clear,
the inherited ACE on the newly created directory MUST have the
ACE4_INHERIT_ONLY_ACE flag set to prevent the directory from being
affected by ACEs meant for non-directories.
When a new directory is created, the server MAY split any inherited
ACE that is both inheritable and effective (in other words, that has
neither ACE4_INHERIT_ONLY_ACE nor ACE4_NO_PROPAGATE_INHERIT_ACE set),
into two ACEs, one with no inheritance flags and one with
ACE4_INHERIT_ONLY_ACE set. (In the case of a dacl or sacl attribute,
both of those ACEs SHOULD also have the ACE4_INHERITED_ACE flag set.)
Shepler, et al. Standards Track [Page 150]RFC 5661 NFSv4.1 January 2010
This makes it simpler to modify the effective permissions on the
directory without modifying the ACE that is to be inherited to the
new directory’s children.
6.4.3.2. Automatic Inheritance
The acl attribute consists only of an array of ACEs, but the sacl
(Section 6.2.3) and dacl (Section 6.2.2) attributes also include an
additional flag field.
struct nfsacl41 {
aclflag4 na41_flag;
nfsace4 na41_aces<>;
};
The flag field applies to the entire sacl or dacl; three flag values
are defined:
const ACL4_AUTO_INHERIT = 0x00000001;
const ACL4_PROTECTED = 0x00000002;
const ACL4_DEFAULTED = 0x00000004;
and all other bits must be cleared. The ACE4_INHERITED_ACE flag may
be set in the ACEs of the sacl or dacl (whereas it must always be
cleared in the acl).
Together these features allow a server to support automatic
inheritance, which we now explain in more detail.
Inheritable ACEs are normally inherited by child objects only at the
time that the child objects are created; later modifications to
inheritable ACEs do not result in modifications to inherited ACEs on
descendants.
However, the dacl and sacl provide an OPTIONAL mechanism that allows
a client application to propagate changes to inheritable ACEs to an
entire directory hierarchy.
A server that supports this performs inheritance at object creation
time in the normal way, and SHOULD set the ACE4_INHERITED_ACE flag on
any inherited ACEs as they are added to the new object.
A client application such as an ACL editor may then propagate changes
to inheritable ACEs on a directory by recursively traversing that
directory’s descendants and modifying each ACL encountered to remove
any ACEs with the ACE4_INHERITED_ACE flag and to replace them by the
new inheritable ACEs (also with the ACE4_INHERITED_ACE flag set). It
uses the existing ACE inheritance flags in the obvious way to decide
Shepler, et al. Standards Track [Page 151]RFC 5661 NFSv4.1 January 2010
which ACEs to propagate. (Note that it may encounter further
inheritable ACEs when descending the directory hierarchy and that
those will also need to be taken into account when propagating
inheritable ACEs to further descendants.)
The reach of this propagation may be limited in two ways: first,
automatic inheritance is not performed from any directory ACL that
has the ACL4_AUTO_INHERIT flag cleared; and second, automatic
inheritance stops wherever an ACL with the ACL4_PROTECTED flag is
set, preventing modification of that ACL and also (if the ACL is set
on a directory) of the ACL on any of the object’s descendants.
This propagation is performed independently for the sacl and the dacl
attributes; thus, the ACL4_AUTO_INHERIT and ACL4_PROTECTED flags may
be independently set for the sacl and the dacl, and propagation of
one type of acl may continue down a hierarchy even where propagation
of the other acl has stopped.
New objects should be created with a dacl and a sacl that both have
the ACL4_PROTECTED flag cleared and the ACL4_AUTO_INHERIT flag set to
the same value as that on, respectively, the sacl or dacl of the
parent object.
Both the dacl and sacl attributes are RECOMMENDED, and a server may
support one without supporting the other.
A server that supports both the old acl attribute and one or both of
the new dacl or sacl attributes must do so in such a way as to keep
all three attributes consistent with each other. Thus, the ACEs
reported in the acl attribute should be the union of the ACEs
reported in the dacl and sacl attributes, except that the
ACE4_INHERITED_ACE flag must be cleared from the ACEs in the acl.
And of course a client that queries only the acl will be unable to
determine the values of the sacl or dacl flag fields.
When a client performs a SETATTR for the acl attribute, the server
SHOULD set the ACL4_PROTECTED flag to true on both the sacl and the
dacl. By using the acl attribute, as opposed to the dacl or sacl
attributes, the client signals that it may not understand automatic
inheritance, and thus cannot be trusted to set an ACL for which
automatic inheritance would make sense.
When a client application queries an ACL, modifies it, and sets it
again, it should leave any ACEs marked with ACE4_INHERITED_ACE
unchanged, in their original order, at the end of the ACL. If the
application is unable to do this, it should set the ACL4_PROTECTED
Shepler, et al. Standards Track [Page 152]RFC 5661 NFSv4.1 January 2010
flag. This behavior is not enforced by servers, but violations of
this rule may lead to unexpected results when applications perform
automatic inheritance.
If a server also supports the mode attribute, it SHOULD set the mode
in such a way that leaves inherited ACEs unchanged, in their original
order, at the end of the ACL. If it is unable to do so, it SHOULD
set the ACL4_PROTECTED flag on the file’s dacl.
Finally, in the case where the request that creates a new file or
directory does not also set permissions for that file or directory,
and there are also no ACEs to inherit from the parent’s directory,
then the server’s choice of ACL for the new object is implementationdependent.
In this case, the server SHOULD set the ACL4_DEFAULTED
flag on the ACL it chooses for the new object. An application
performing automatic inheritance takes the ACL4_DEFAULTED flag as a
sign that the ACL should be completely replaced by one generated
using the automatic inheritance rules.