Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1340544 > unrolled thread

Re: richacl(7) man page review comments

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: richacl(7) man page review comments "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-02-23 12:00 +0100
    Re: richacl(7) man page review comments Andreas Gruenbacher <agruenba@redhat.com> - 2016-02-23 12:20 +0100
    Re: richacl(7) man page review comments Andreas Gruenbacher <agruenba@redhat.com> - 2016-02-23 16:10 +0100
      Re: richacl(7) man page review comments Andreas Gruenbacher <agruenba@redhat.com> - 2016-02-23 20:10 +0100

#1340544 — Re: richacl(7) man page review comments

Hi Andreas,

On 02/22/2016 03:46 PM, Andreas Gruenbacher wrote:
> Hi Michael,
> 
> On Sun, Feb 21, 2016 at 10:40 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> I've once more pulled from the latest git; here's some more comments.
> 
> thanks again. I've updated the repo with your changes.

Next round :-). Just a few quick comments while I'm on a train ride.

> .\"
> .\" RichACL Manual Pages
> .\"
> .\" Copyright (C) 2015,2016  Red Hat, Inc.
> .\" Written by Andreas Gruenbacher <agruenba@redhat.com>
> .\" This is free documentation; you can redistribute it and/or
> .\" modify it under the terms of the GNU General Public License as
> .\" published by the Free Software Foundation; either version 2 of
> .\" the License, or (at your option) any later version.
> .\"
> .\" The GNU General Public License's references to "object code"
> .\" and "executables" are to be interpreted as the output of any
> .\" document formatting or typesetting system, including
> .\" intermediate and printed output.
> .\"
> .\" This manual is distributed in the hope that it will be useful,
> .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
> .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> .\" GNU General Public License for more details.
> .\"
> .\" You should have received a copy of the GNU General Public
> .\" License along with this manual.  If not, see
> .\" <http://www.gnu.org/licenses/>.
> .\"
> .de URL
> \\$2 \(laURL: \\$1 \(ra\\$3
> ..
> .if \n[.g] .mso www.tmac
> .TH RICHACL 7 2015-09-01 "Linux" "Rich Access Control Lists"
> .SH NAME
> richacl \- Rich Access Control Lists
> .SH DESCRIPTION
> Rich Access Control Lists (RichACLs) are an extension of the POSIX file
> permission model (see
> .BR acl (5))
> to support
> .URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lists"
> on local and remote-mounted filesystems.
> 
> A RichACL can always be translated into an equivalent NFSv4 ACL which grants
> the same permissions.
> 
> RichACLs can be enabled on supported local filesystems (currently, ext4 and
> XFS).  The in-kernel NFSv4 server and client also include RichACL support.
> 
> Enabling RichACLs disables POSIX Access Control Lists; the two ACL models
> cannot coexist on the same filesystem.
> 
> When used on a filesystem that does not support RichACLs, the
> .BR getrichacl (1)
> and
> .BR setrichacl (1)
> utilities will operate on the file permission bits instead:
> .BR getrichacl (1)
> will display the file permission bits as a RichACL; when a RichACL
> is set with
> .BR setrichacl (1)
> which can be represented exactly by the file permission bits,
> .BR setrichacl (1)
> will set the file permission bits instead.  An attempt to set a RichACL that
> cannot be represented exactly by the file permission bits results in an error.
> 
> .SS Structure of RichACLs
> 
> RichACLs consist of a number of ACL entries, three file masks, and a set of
> flags specifying attributes of the ACL as a whole (by contrast with the
> per-ACL-entry flags described below).
> 
> Each of the ACL entries allows or denies some permissions to a particular user,
> group, or special identifier. An ACL entry consists of four fields:
> 
> .IP \(bu 2
> A tag which specifies the user, group, or special identifier the entry applies
> to.  Special identifiers can be the file owner
> .RB ( owner@ ),
> the owning group
> .RB ( group@ ),
> or everyone
> .RB ( everyone@ ).
> .IP \(bu
> A set of permissions the entry allows or denies.
> .IP \(bu
> A set of flags that indicate whether the user or group identifier is mapped or
> unmapped, and whether the entry has been and can be inherited.
> .IP \(bu
> A type field indicating whether the entry allows or denies the permissions
> specified in the second field.
> .PP
> The owner, group, and other file masks further control which permissions the
> ACL grants, subject to the
> .BR masked "\ (" m )
> and
> .BR write_through "\ (" w )
> ACL flags: when the permissions of a file or directory are changed with
> .BR chmod (2),
> the file masks are set based on the new file mode, and the
> .B masked
> and
> .B write_through
> ACL flags are set. Likewise, when a new file or directory inherits an ACL from
> its parent directory, the file masks are set to the intersection between the
> permissions granted by the inherited ACL and the
> .I mode
> parameter as given to
> .BR open "(2), " mkdir (2),
> and similar, and the
> .B masked
> ACL flag is set. In both cases, the file masks limit the permissions that the
> ACL will grant.
> 
> The purpose of the file masks is to allow traditional POSIX applications which
> are unaware of RichACLs to place limits on the permissions granted by the
> RichACL without causing the ACL entries to be modified.  Without the file mask,
> the only alternative would be for the kernel to directly modify the ACL
> entries.  However, this latter approach could have a "hysteresis effect",
> whereby a RichACL-unaware application that performs a transition from one file
> mode to another file mode and then back to the original file mode could cause
> destruction of the permission information in ACL entries.  When creating files
> or directories, the
> .I mode
> parameter to
> .BR open "(2), " mkdir (2),
> and similar would cause the same effect.

s/cause/have/

> 
> Note that entries with the identifier
> .B everyone@
> apply to all processes, whereas the \(lqother\(rq file permissions and
> \(lqother\(rq entries in POSIX ACLs apply to all processes which are not the

So, I still think it's helpful to mention ACL_OTHER here. How about:

s/\\(lqother\\(rq/\\(lqother\\(rq (\\fBACL_OTHER\\fP)/

> owner, are not in the owning group, and do not match a user or group mentioned
> in the ACL.
> 
> Unlike POSIX ACLs, RichACLs do not have separate \(lqaccess\(rq ACLs that
> define the access permissions and \(lqdefault\(rq ACLs that define the
> inheritable permissions.  Instead, flags on each ACL entry determine whether
> the entry is effective during access checks and/or inheritable.
> 
> 
> .SS ACL flags
> 
> The following ACL flags are defined:
> 
> .TP
> .BR masked "\ (" m )
> When set, the file masks define upper limits on the permissions the ACL may
> grant.  When not set, the file masks are ignored.
> .TP
> .BR write_through "\ (" w )
> When this flag and the
> .B masked
> flag are both set, the owner and other file masks define the actual permissions
> granted to the file owner and to others instead of defining an upper limit.
> When the
> .B masked
> flag is not set, the
> .B write_through
> flag has no effect.
> .TP
> .BR auto_inherit "\ (" a )
> Automatic Inheritance is enabled.  See
> .IR "Automatic Inheritance" .
> .TP
> .BR protected "\ (" p )
> The ACL is protected from modification by Automatic
> Inheritance.
> .TP
> .BR defaulted "\ (" d )
> Indicates that the ACL has been assigned in an application-dependent way when
> the file or directory was created; it has neither been inherited nor set
> explicitly. ACLs of files created on Linux will never have the
> .B defaulted
> flag set, but the flag may be set on files created on or copied over from
> other operating systems.  When this flag is set for an ACL, Automatic
> Inheritance will completely replace the ACL.
> 
> .SS ACL entry flags
> 
> The following flags on ACL entries are defined:
> 
> .TP
> .BR file_inherit "\ (" f )
> When this flag appears in the ACL entry of a directory, then:
> .RS
> .IP \(bu 2
> That entry is inherited by new files created in the directory such that the
> permissions of the entry apply to the file (the inheritance flags of the
> inherited entry are cleared).
> .IP \(bu
> The entry is is inherited by new subdirectories created in the directory such
> that the permissions of the entry will apply to new files created in the
> subdirectory.
> .RE
> .TP
> .BR dir_inherit "\ (" d )
> When this flag appears in the ACL entry of a directory, then that entry is
> inherited by new subdirectories created in the directory such that the
> permissions of the entry apply to the subdirectory (the
> .B inherit_only
> flag is cleared).
> .TP
> .BR no_propagate "\ (" n )
> Inheritance stops at the next subdirectory level.  When a file or directory
> inherits an entry that has this flag set, the
> .BR file_inherit ", " dir_inherit ", " no_propagate ", and " inherit_only
> flags are cleared.
> .TP
> .BR inherit_only "\ (" i )
> The entry defines inheritable permissions only and is ignored for access
> checking.  When a file or directory inherits an entry that has this flag set,
> the flag is cleared.
> .TP
> .BR inherited "\ (" a )
> The entry has been automatically inherited from the parent directory.
> .TP
> .BR unmapped "\ (" u )
> The user or group identifier is a textual string and is not mapped to a numeric
> user or group identifier.  ACLs with unmapped identifiers can occur on NFSv4
> mounted filesystems when the client cannot determine numeric user or group
> identifiers for some of the NFSv4 user@domain or group@domain who values.  They
> cannot be assigned to local files or directories.
> 
> .SS Permissions
> 
> The following permissions are defined for RichACL entries and for the three
> file masks:
> 
> .TP
> .BR read_data " / " list_directory "\ (" r )
> For a file: read the data of the file.
> For a directory: list the contents of the directory.
> .TP
> .BR write_data " / " add_file "\ (" w )
> For a file: modify the data of the file; does not include opening the file in
> append mode.
> For a directory: add a new file in the directory.
> .TP
> .BR append_data " / " add_subdirectory "\ (" p )
> For a file: open the file in append mode.
> For a directory: create a subdirectory in the directory.
> .TP
> .BR execute "\ (" x )
> For a file: execute the file.
> For a directory: traverse (search) the directory.
> .TP
> .BR delete_child "\ (" d )
> Delete a file or directory within a directory.  This permission is meaningful
> only for directories.
> .TP
> .BR delete "\ (" D )
> Delete the file or directory.
> .TP
> .BR read_attributes "\ (" a )
> Read basic attributes of a file or directory (see
> .BR stat (2)).
> This permission is defined by NFSv4.  It is stored, but ignored.  Reading basic
> attributes of files and directories is always allowed on Linux.
> .TP
> .BR write_attributes "\ (" A )
> Change the times associated with a file or directory to an arbitrary value.
> This permission is always implicitly granted to the file owner.
> .TP
> .BR read_acl "\ (" c )
> Read the ACL of a file or directory. Like reading the basic file attributes (the
> .B read_attributes
> permission), reading ACLs is always allowed in Linux.
> .TP
> .BR write_acl "\ (" C )
> Change the ACL or file mode of a file or directory.
> .TP
> .BR write_owner "\ (" o )
> Take ownership of a file or directory.  Change the owning group of a file or
> directory to a group of which the calling process is a member.
> .TP
> .ad l
> .BR read_named_attrs "\ (" R "), " write_named_attrs "\ (" W "), " synchronize "\ (" S "), " write_retention "\ (" e "), " write_retention_hold "\ (" E )
> .ad
> These permissions are defined by NFSv4 and NFSv4.1.  They are stored, but ignored.
> .PP
> For the
> .BR r ", " w ", and " p
> permissions, which have different long forms for files and directories, the
> .BR getrichacl (1)
> utility will output the appropriate form(s) depending on the context.
> The
> .BR setrichacl (1)
> utility will accept either form for any file type.
> 
> .SS Text form
> The common textual representation of a RichACL consists of the colon-separated
> fields of the ACL flags, file masks, and ACL entries in the following
> format:
> .TP
> \fBflags:\fR\fIacl_flags\fR
> The ACL flags.
> .TP
> \fBowner:\fR\fIperm\fR\fB::mask\fR, \fBgroup:\fR\fIperm\fR\fB::mask\fR, \fBother:\fR\fIperm\fR\fB::mask\fR
> The file masks and their permissions.
> .TP
> \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:allow\fR, \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:deny\fR
> For each ACL entry, who the entry applies to, the permissions of the entry, the
> entry flags, and the entry type. The \fIwho\fR field is one of the following:
> .RS
> .IP \(bu 2
> One of the special identifiers:
> .BR owner@ ", " group@ ", or " everyone@ ,
> .IP \(bu
> A
> .BR user: " or " u:
> prefix followed by a user name or user ID that designates a specific user,
> .IP \(bu
> A
> .BR group: " or " g:
> prefix followed by a group name or group ID that designates a specific group.
> .RE
> .PP
> The entries are comma, whitespace, or newline separated.

s/entries/fields of an ACL entry/ (?)

> 
> Flags and permissions have single-letter as well as long forms, as listed under
> .IR "ACL flags" ,
> .IR "ACL entry flags" ,
> and
> .IR Permissions .
> When the single-letter forms are used, the flags or permissions are
> concatenated. When the long forms are used, the flags or permissions are
> separated by slashes.  To align permissions or flags vertically, dashes can be
> used for padding.
> 
> .SS Setting and modifying file permissions
> The access permissions for a file can either be set by assigning an Access
> Control List
> .RB ( setrichacl (1))
> or by changing the file mode permission bits
> .RB ( chmod (1)).
> In addition, a file can inherit an ACL from its parent directory at creation
> time as described under
> .IR "Permissions at file-creation time" .
> 
> .SS Assigning an Access Control List
> When assigning an ACL to a file, unless explicitly specified, the owner, group,
> and other file masks will be computed from the ACL entries as described in
> the section
> .IR "Computing the maximum file masks" .
> The owner, group, and other file mode permission bits are then each set from
> the owner, group, and other file mask as follows:
> .IP \(bu 2
> If the file mask includes the
> .B r
> permission, the read
> file mode permission bit will be set.
> .IP \(bu
> If the file mask includes the
> .B w
> or
> .B p
> permission, the write file mode permission bit will be set.
> .IP \(bu
> If the file mask includes the
> .B x
> permission, the execute file mode permission bit will be set.
> .PP
> If the ACL can be represented exactly by the file mode permission bits, the
> file permission bits are set to match the ACL and no ACL is stored.  (When the
> ACL of a file is requested which doesn't have an ACL, the file mode permission
> bits are converted into an equivalent ACL.)
> 
> .SS Changing the file mode permission bits
> When changing the file mode permission bits with
> .BR chmod (1),
> the owner, group, and other file permission bits are set to the permission bits
> in the new mode, and the owner, group, and other file masks are set based on
> the new mode bits as follows:
> .IP \(bu 2
> If the read bit in a set of permissions is set, the
> .B r
> permission in the corresponding file mask will be set.
> .IP \(bu
> If the write bit in a set of permissions is set, the
> .B w
> and
> .B p
> permissions in the corresponding file mask will be set.
> .IP \(bu
> If the execute bit in a set of permissions is set, the
> .B x
> permission in the corresponding file mask will be set.
> .PP
> In addition, the
> .B masked
> and
> .B write_through
> ACL flags are set. This has the
> effect of limiting the permissions granted by the ACL to the file mode
> permission bits; in addition, the owner is granted the owner mode bits and
> others are granted the other mode bits. If the
> .B auto_inherit
> flag is set, the
> .B protected
> flag is also set to prevent the Automatic Inheritance algorithm from modifying
> the ACL.
> 
> .SS Permissions at file-creation time
> When a directory has any inheritable ACL entries, the following
> happens when a file or directory is created inside that directory:
> .RS 4

Remove preceding line.

> .IP 1. 4
> A file created inside that directory will inherit all of the ACL entries that
> have the
> .B file_inherit
> flag set, and all inheritance-related flags in the inherited entries flag will
> be cleared.
> 
> A subdirectory created inside that directory will inherit all of the ACL
> entries that either have the
> .B dir_inherit
> flag set, or the
> .B file_inherit
> flag set and the
> .B no_propagate
> flag not set.  Entries whose
> .B dir_inherit
> flag is set will have their
> .B inherit_only
> flag cleared, and entries whose
> .B dir_inherit
> flag is not set will have their
> .B inherit_only
> flag set.  Finally, entries whose
> .B no_propagate
> flag is set will have all inheritance-related flags cleared.
> .IP 2.
> If the parent directory's ACL has the
> .B auto_inherit
> flag set, the inherited ACL will have its

s/the/then the/
(For ease of parsing)

> .B auto_inherit
> flag set, and all entries will have their
> .B inherited
> flag set.  Otherwise, the
> .B auto_inherit
> and
> .B inherited
> flags are cleared.
> .IP 3.
> The three file masks are computed from the inherited ACL as described in
> the section
> .IR "Computing the maximum file masks" .
> .IP 4.
> The three sets of permissions for the owner, the group, and for others in
> the \fImode\fR parameter as given to
> .BR open (2),
> .BR mkdir (2),
> and similar are converted into sets of RichACL permissions. The correspondence
> between mask flags and RichACL permission bits is described in the section
> .IR "Changing the file mode permission bits" .
> Any RichACL permissions not included in those sets are
> removed from the owner, group, and other file masks. The file mode permission
> bits are then computed from the file masks as described in the section
> .IR "Assigning an Access Control List" .
> The process umask (see
> .BR umask (2))
> is ignored.
> .IP 5.
> The
> .B masked
> ACL flag is set. The
> .B write_through
> ACL flag remains cleared. In addition, if the
> .B auto_inherit
> flag of the inherited ACL is set, the
> .B protected
> flag is also set to prevent the Automatic Inheritance algorithm from modifying
> the ACL.
> .RE

Remove preceding line.

> .PP
> When a directory does not have inheritable ACL entries, files and directories
> created inside that directory will not be assigned Access Control Lists and the
> file mode permission bits will be set to (\fImode\fR\ &\ ~\fIumask\fR) where
> \fImode\fR is the mode argument of the relevant system call and \fIumask\fR is
> the process umask (see
> .BR umask (2)).
> 
> .SS Automatic Inheritance
> Automatic Inheritance is a mechanism that allows permission changes to
> propagate from a directory to files and subdirectories inside that directory,
> recursively.  Propagation is carried out by the process changing the directory
> permissions (usually,
> .BR setrichacl (1));
> it happens without user intervention albeit not entirely automatically.
> 
> A significant limitation is that this mechanism works only as long as files

s/limitation/limitation of the Automatic Inheritance feature/

> are created without explicitly specifying the file permissions to use. The
> standard system calls for creating files and directories
> .RB ( creat (2),
> .BR open (2),
> .BR mkdir (2),
> .BR mknod (2))

s/)$/,\nand so on)/

(And, I'd drop creat(2) from that list of examples. It's ancient and
obsolete; no need to encourageits use.)

> all have mandatory mode parameters which define the maximum allowed permissions
> of the new files. To take account of this restriction, the
> .B protected
> ACL flag must be set if the
> .B inherited
> flag is set. This effectively disables Automatic Inheritance for that
> particular file.
> 
> Notwithstanding the aforementioned limitation, Automatic Inheritance still
> remains useful for network protocols like NFSv4 and SMB, which both support
> creating files and directories without defining their permissions. These
> protocols can implement those operations by using the standard system calls and
> by then undoing the effect of applying the mode parameters.
> 
> When the ACL of a directory is changed, the following happens for each entry
> (\(lqchild\(rq) inside that directory:
> .IP 1. 4
> If the entry is a symbolic link, skip the child.
> .IP 2.
> If the
> .B auto_inherit
> flag of the entry's ACL is not set or the
> .B protected
> flag is set, skip the child.
> .IP 3.
> With the child's ACL:
> .RS 4
> .IP a) 4
> If the
> .B defaulted
> flag is set, replace the ACL with an empty ACL
> with the
> .B auto_inherit
> flag set.
> .IP b)
> Delete all entries which have the
> .B inherited
> flag set.
> .IP c)
> Append all entries inherited from the parent directory according to step 1 of
> the algorithm described under
> .IR "Permissions at file-creation time".
> Set the
> .B inherited
> flag of each of these entries.
> .IP d)
> Recompute the file masks.

At th end of the last section, add:

        as descibed in the section "...."

> .RE
> .IP 4.
> If the child is a directory, recursively apply this algorithm.
> 
> .SS Access check algorithm
> 
> When a process requests a particular kind of access (expressed as a set of
> RichACL permissions) to a file, the following algorithm determines whether the
> access is granted or denied:
> 
> .IP 1. 4
> If the
> .B masked
> ACL flag is set, then:
> .RS 4
> .IP a) 4
> If the
> .B write_through
> ACL flag is set, then:
> .RS 4
> .IP \(bu 2
> If the requesting process is the file owner, then access is granted if the
> owner mask includes the requested permissions, and is otherwise denied.
> .IP \(bu
> If the requesting process is not the file owner and it is in the owning group or matches any ACL entries other than
> .BR everyone@ ,
> proceed to step b).
> .IP \(bu
> If the requesting process is not the file owner, is not in the owning group,
> and no ACL entries other than
> .B everyone@
> match the process, then access is granted if the other mask includes the
> requested permissions, and is otherwise denied.
> .RE
> .IP b)
> If any of the following is true:
> .RS 4
> .IP \(bu 2
> the requesting process is the file owner and the owner mask does not include all
> requested permissions,
> .IP \(bu
> the requesting process is not the file owner and it is in the owning group or
> matches any ACL entries other than
> .BR everyone@ ,
> and the group mask does not include all requested permissions,
> .IP \(bu
> the requesting process is not the file owner, not in the owning group, it
> matches no ACL entries other than
> .BR everyone@ ,
> and the other mask does not include all requested permissions,
> .PP
> then access is denied.
> .RE
> .RE
> .IP 2.
> Upon reaching this point, the determination of whether or not access is granted
> is made by scanning all ACL entries to see if one or more applicable entries
> together grant a cumulative set of permissions that matches the requested
> permissions or there is an applicable entry that explicitly denies one or more
> of the requested permissions.  The scan of all ACL entries begins by first
> initializing the set of remaining permissions (i.e., those that have not yet
> been satisfied during the scan) to be the set of requested permissions. Then
> the ACL entries are scanned
> .IR "in order" ,
> and for each entry:
> .RS 4
> .IP a) 4
> If the
> .B inherit_only
> or
> .B unmapped
> flags are set, continue with the next ACL entry.
> .IP b)
> If any of the following is true:
> .RS 4
> .IP \(bu 2
> the entry's identifier is
> .B owner@
> and the requesting process is the file owner,
> .IP \(bu
> the entry's identifier is
> .B group@
> and the requesting process is in the owning group,
> .IP \(bu
> the entry's identifier is a user and the requesting process is owned by that
> user,
> .IP \(bu
> the entry's identifier is a group and the requesting process is a member in
> that group,
> .IP \(bu
> the entry's identifier is
> .BR everyone@ ,
> .PP
> then the entry matches the process; proceed to the next step. Otherwise,
> continue with the next ACL entry.
> .RE
> .IP c)
> If the entry denies any of the remaining permissions, access is denied.
> .IP d)
> If the entry allows any of the remaining permissions, then:
> .RS 4
> .IP \(bu 2
> If the
> .B masked
> ACL flag is set and the entry's identifier is not
> .B owner@
> or
> .BR everyone@
> or is a user entry matching the file owner, remove all permissions from the
> remaining permissions which are both allowed by the entry and included in the
> group mask,
> .IP \(bu
> Otherwise, remove all permissions from the remaining permissions which are
> allowed by the entry.
> .RE
> .RE
> .IP 3.
> If there are no more remaining permissions, access is allowed. Otherwise,
> access is denied.
> .PP
> In this algorithm, a process can gain the permissions it requires by
> accumulating them from multiple RichACL entries.  This is in contrast with
> POSIX ACLs, where access is only granted if an ACL entry exists that matches
> the requesting process and includes all the requested permissions.
> 
> .SS Computing the maximum file masks
> When setting an ACL and no file masks have been explicitly specified and when
> inheriting an ACL from the parent directory, the following algorithm is used

s/directory/directory (as described in section "....")/

> for computing the file masks:
> 
> .IP 1. 4
> Clear the owner, group, and other file masks. Remember which permissions have
> already been processed (initially, the empty set).
> .IP 2.
> For each ACL entry:
> .RS 4
> .IP \(bu 2
> If the
> .B inherit_only
> flag is set, skip the entry.
> .IP \(bu
> Otherwise, compute which permissions the entry allows or denies that have not
> been processed yet (the remaining permissions).
> .IP \(bu
> If the entry is an
> .B owner@
> entry, add the remaining permissions to the owner mask for
> .B allow
> entries, and remove the remaining permissions from the owner mask for
> .B deny
> entries.
> .IP \(bu
> Otherwise, if the entry is an
> .B everyone@
> entry, proceed as with
> .B owner@
> entries but add or remove the remaining permissions from the owner, group, and
> other file masks.
> .IP \(bu
> Otherwise, proceed as with
> .B owner@
> entries but add or remove the remaining permissions from the owner and group
> file masks.
> .IP \(bu
> Add the entry's permissions to the processed permissions.
> .RE
> .PP
> The resulting file masks represent the ACL as closely as possible. With these
> file masks, the effective permissions that the ACL grants will be the same when
> the
> .B masked
> flag is set as when it is not set.
> 
> .\" .SH BUGS
> .SH AUTHOR
> Written by Andreas Grünbacher <agruenba@redhat.com>.
> 
> Please send your bug reports, suggested features and comments to the above address.
> 
> .SH CONFORMING TO
> Rich Access Control Lists are Linux-specific.
> .SH SEE ALSO
> .BR chmod (1),
> .BR getrichacl (1),
> .BR ls (1),
> .BR setrichacl (1)
> .BR stat (2),
> .BR umask (2),
> .BR acl (5)
> .\" librichacl

So, in terms of actually testing this stuff, is it just a matter of
applying your patch series to the kernel, building the kernel, pulling
the RichACL user-space tools from Git, and mount(8)ing a filesystem with
the right option?

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [next] | [standalone]

#1340553

On Tue, Feb 23, 2016 at 11:58 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> So, in terms of actually testing this stuff, is it just a matter of
> applying your patch series to the kernel, building the kernel, pulling
> the RichACL user-space tools from Git, and mount(8)ing a filesystem with
> the right option?

You'd create a test filesystem with the appropriate feature flag set
(mkfs.ext4 -O richacl2 / mkfs.xfs -m richacl=1), RichACLs are not
enabled by mount options anymore. This will obviously require versions
of e2fsprogs / xfsprogs that understand the feature. If you want
coreutils support which isn't strictly necessary, you'll need the
patched version too. Other than that, it's really simple.

Andreas

[toc] | [prev] | [next] | [standalone]

#1340739

Hi Michael,

On Tue, Feb 23, 2016 at 11:58 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 02/22/2016 03:46 PM, Andreas Gruenbacher wrote:
>> On Sun, Feb 21, 2016 at 10:40 PM, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
>>> I've once more pulled from the latest git; here's some more comments.
>>
>> thanks again. I've updated the repo with your changes.
>
> Next round :-). Just a few quick comments while I'm on a train ride.

applied, thanks.

>> .\"
>> .\" RichACL Manual Pages
>> .\"
>> .\" Copyright (C) 2015,2016  Red Hat, Inc.
>> .\" Written by Andreas Gruenbacher <agruenba@redhat.com>
>> .\" This is free documentation; you can redistribute it and/or
>> .\" modify it under the terms of the GNU General Public License as
>> .\" published by the Free Software Foundation; either version 2 of
>> .\" the License, or (at your option) any later version.
>> .\"
>> .\" The GNU General Public License's references to "object code"
>> .\" and "executables" are to be interpreted as the output of any
>> .\" document formatting or typesetting system, including
>> .\" intermediate and printed output.
>> .\"
>> .\" This manual is distributed in the hope that it will be useful,
>> .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
>> .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> .\" GNU General Public License for more details.
>> .\"
>> .\" You should have received a copy of the GNU General Public
>> .\" License along with this manual.  If not, see
>> .\" <http://www.gnu.org/licenses/>.
>> .\"
>> .de URL
>> \\$2 \(laURL: \\$1 \(ra\\$3
>> ..
>> .if \n[.g] .mso www.tmac
>> .TH RICHACL 7 2015-09-01 "Linux" "Rich Access Control Lists"
>> .SH NAME
>> richacl \- Rich Access Control Lists
>> .SH DESCRIPTION
>> Rich Access Control Lists (RichACLs) are an extension of the POSIX file
>> permission model (see
>> .BR acl (5))
>> to support
>> .URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lists"
>> on local and remote-mounted filesystems.
>>
>> A RichACL can always be translated into an equivalent NFSv4 ACL which grants
>> the same permissions.
>>
>> RichACLs can be enabled on supported local filesystems (currently, ext4 and
>> XFS).  The in-kernel NFSv4 server and client also include RichACL support.
>>
>> Enabling RichACLs disables POSIX Access Control Lists; the two ACL models
>> cannot coexist on the same filesystem.
>>
>> When used on a filesystem that does not support RichACLs, the
>> .BR getrichacl (1)
>> and
>> .BR setrichacl (1)
>> utilities will operate on the file permission bits instead:
>> .BR getrichacl (1)
>> will display the file permission bits as a RichACL; when a RichACL
>> is set with
>> .BR setrichacl (1)
>> which can be represented exactly by the file permission bits,
>> .BR setrichacl (1)
>> will set the file permission bits instead.  An attempt to set a RichACL that
>> cannot be represented exactly by the file permission bits results in an error.
>>
>> .SS Structure of RichACLs
>>
>> RichACLs consist of a number of ACL entries, three file masks, and a set of
>> flags specifying attributes of the ACL as a whole (by contrast with the
>> per-ACL-entry flags described below).
>>
>> Each of the ACL entries allows or denies some permissions to a particular user,
>> group, or special identifier. An ACL entry consists of four fields:
>>
>> .IP \(bu 2
>> A tag which specifies the user, group, or special identifier the entry applies
>> to.  Special identifiers can be the file owner
>> .RB ( owner@ ),
>> the owning group
>> .RB ( group@ ),
>> or everyone
>> .RB ( everyone@ ).
>> .IP \(bu
>> A set of permissions the entry allows or denies.
>> .IP \(bu
>> A set of flags that indicate whether the user or group identifier is mapped or
>> unmapped, and whether the entry has been and can be inherited.
>> .IP \(bu
>> A type field indicating whether the entry allows or denies the permissions
>> specified in the second field.
>> .PP
>> The owner, group, and other file masks further control which permissions the
>> ACL grants, subject to the
>> .BR masked "\ (" m )
>> and
>> .BR write_through "\ (" w )
>> ACL flags: when the permissions of a file or directory are changed with
>> .BR chmod (2),
>> the file masks are set based on the new file mode, and the
>> .B masked
>> and
>> .B write_through
>> ACL flags are set. Likewise, when a new file or directory inherits an ACL from
>> its parent directory, the file masks are set to the intersection between the
>> permissions granted by the inherited ACL and the
>> .I mode
>> parameter as given to
>> .BR open "(2), " mkdir (2),
>> and similar, and the
>> .B masked
>> ACL flag is set. In both cases, the file masks limit the permissions that the
>> ACL will grant.
>>
>> The purpose of the file masks is to allow traditional POSIX applications which
>> are unaware of RichACLs to place limits on the permissions granted by the
>> RichACL without causing the ACL entries to be modified.  Without the file mask,
>> the only alternative would be for the kernel to directly modify the ACL
>> entries.  However, this latter approach could have a "hysteresis effect",
>> whereby a RichACL-unaware application that performs a transition from one file
>> mode to another file mode and then back to the original file mode could cause
>> destruction of the permission information in ACL entries.  When creating files
>> or directories, the
>> .I mode
>> parameter to
>> .BR open "(2), " mkdir (2),
>> and similar would cause the same effect.
>
> s/cause/have/
>
>>
>> Note that entries with the identifier
>> .B everyone@
>> apply to all processes, whereas the \(lqother\(rq file permissions and
>> \(lqother\(rq entries in POSIX ACLs apply to all processes which are not the
>
> So, I still think it's helpful to mention ACL_OTHER here. How about:
>
> s/\\(lqother\\(rq/\\(lqother\\(rq (\\fBACL_OTHER\\fP)/
>
>> owner, are not in the owning group, and do not match a user or group mentioned
>> in the ACL.
>>
>> Unlike POSIX ACLs, RichACLs do not have separate \(lqaccess\(rq ACLs that
>> define the access permissions and \(lqdefault\(rq ACLs that define the
>> inheritable permissions.  Instead, flags on each ACL entry determine whether
>> the entry is effective during access checks and/or inheritable.
>>
>>
>> .SS ACL flags
>>
>> The following ACL flags are defined:
>>
>> .TP
>> .BR masked "\ (" m )
>> When set, the file masks define upper limits on the permissions the ACL may
>> grant.  When not set, the file masks are ignored.
>> .TP
>> .BR write_through "\ (" w )
>> When this flag and the
>> .B masked
>> flag are both set, the owner and other file masks define the actual permissions
>> granted to the file owner and to others instead of defining an upper limit.
>> When the
>> .B masked
>> flag is not set, the
>> .B write_through
>> flag has no effect.
>> .TP
>> .BR auto_inherit "\ (" a )
>> Automatic Inheritance is enabled.  See
>> .IR "Automatic Inheritance" .
>> .TP
>> .BR protected "\ (" p )
>> The ACL is protected from modification by Automatic
>> Inheritance.
>> .TP
>> .BR defaulted "\ (" d )
>> Indicates that the ACL has been assigned in an application-dependent way when
>> the file or directory was created; it has neither been inherited nor set
>> explicitly. ACLs of files created on Linux will never have the
>> .B defaulted
>> flag set, but the flag may be set on files created on or copied over from
>> other operating systems.  When this flag is set for an ACL, Automatic
>> Inheritance will completely replace the ACL.
>>
>> .SS ACL entry flags
>>
>> The following flags on ACL entries are defined:
>>
>> .TP
>> .BR file_inherit "\ (" f )
>> When this flag appears in the ACL entry of a directory, then:
>> .RS
>> .IP \(bu 2
>> That entry is inherited by new files created in the directory such that the
>> permissions of the entry apply to the file (the inheritance flags of the
>> inherited entry are cleared).
>> .IP \(bu
>> The entry is is inherited by new subdirectories created in the directory such
>> that the permissions of the entry will apply to new files created in the
>> subdirectory.
>> .RE
>> .TP
>> .BR dir_inherit "\ (" d )
>> When this flag appears in the ACL entry of a directory, then that entry is
>> inherited by new subdirectories created in the directory such that the
>> permissions of the entry apply to the subdirectory (the
>> .B inherit_only
>> flag is cleared).
>> .TP
>> .BR no_propagate "\ (" n )
>> Inheritance stops at the next subdirectory level.  When a file or directory
>> inherits an entry that has this flag set, the
>> .BR file_inherit ", " dir_inherit ", " no_propagate ", and " inherit_only
>> flags are cleared.
>> .TP
>> .BR inherit_only "\ (" i )
>> The entry defines inheritable permissions only and is ignored for access
>> checking.  When a file or directory inherits an entry that has this flag set,
>> the flag is cleared.
>> .TP
>> .BR inherited "\ (" a )
>> The entry has been automatically inherited from the parent directory.
>> .TP
>> .BR unmapped "\ (" u )
>> The user or group identifier is a textual string and is not mapped to a numeric
>> user or group identifier.  ACLs with unmapped identifiers can occur on NFSv4
>> mounted filesystems when the client cannot determine numeric user or group
>> identifiers for some of the NFSv4 user@domain or group@domain who values.  They
>> cannot be assigned to local files or directories.
>>
>> .SS Permissions
>>
>> The following permissions are defined for RichACL entries and for the three
>> file masks:
>>
>> .TP
>> .BR read_data " / " list_directory "\ (" r )
>> For a file: read the data of the file.
>> For a directory: list the contents of the directory.
>> .TP
>> .BR write_data " / " add_file "\ (" w )
>> For a file: modify the data of the file; does not include opening the file in
>> append mode.
>> For a directory: add a new file in the directory.
>> .TP
>> .BR append_data " / " add_subdirectory "\ (" p )
>> For a file: open the file in append mode.
>> For a directory: create a subdirectory in the directory.
>> .TP
>> .BR execute "\ (" x )
>> For a file: execute the file.
>> For a directory: traverse (search) the directory.
>> .TP
>> .BR delete_child "\ (" d )
>> Delete a file or directory within a directory.  This permission is meaningful
>> only for directories.
>> .TP
>> .BR delete "\ (" D )
>> Delete the file or directory.
>> .TP
>> .BR read_attributes "\ (" a )
>> Read basic attributes of a file or directory (see
>> .BR stat (2)).
>> This permission is defined by NFSv4.  It is stored, but ignored.  Reading basic
>> attributes of files and directories is always allowed on Linux.
>> .TP
>> .BR write_attributes "\ (" A )
>> Change the times associated with a file or directory to an arbitrary value.
>> This permission is always implicitly granted to the file owner.
>> .TP
>> .BR read_acl "\ (" c )
>> Read the ACL of a file or directory. Like reading the basic file attributes (the
>> .B read_attributes
>> permission), reading ACLs is always allowed in Linux.
>> .TP
>> .BR write_acl "\ (" C )
>> Change the ACL or file mode of a file or directory.
>> .TP
>> .BR write_owner "\ (" o )
>> Take ownership of a file or directory.  Change the owning group of a file or
>> directory to a group of which the calling process is a member.
>> .TP
>> .ad l
>> .BR read_named_attrs "\ (" R "), " write_named_attrs "\ (" W "), " synchronize "\ (" S "), " write_retention "\ (" e "), " write_retention_hold "\ (" E )
>> .ad
>> These permissions are defined by NFSv4 and NFSv4.1.  They are stored, but ignored.
>> .PP
>> For the
>> .BR r ", " w ", and " p
>> permissions, which have different long forms for files and directories, the
>> .BR getrichacl (1)
>> utility will output the appropriate form(s) depending on the context.
>> The
>> .BR setrichacl (1)
>> utility will accept either form for any file type.
>>
>> .SS Text form
>> The common textual representation of a RichACL consists of the colon-separated
>> fields of the ACL flags, file masks, and ACL entries in the following
>> format:
>> .TP
>> \fBflags:\fR\fIacl_flags\fR
>> The ACL flags.
>> .TP
>> \fBowner:\fR\fIperm\fR\fB::mask\fR, \fBgroup:\fR\fIperm\fR\fB::mask\fR, \fBother:\fR\fIperm\fR\fB::mask\fR
>> The file masks and their permissions.
>> .TP
>> \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:allow\fR, \fIwho\fR\fB:\fR\fIperm\fR\fB:\fR\fIflags\fR\fB:deny\fR
>> For each ACL entry, who the entry applies to, the permissions of the entry, the
>> entry flags, and the entry type. The \fIwho\fR field is one of the following:
>> .RS
>> .IP \(bu 2
>> One of the special identifiers:
>> .BR owner@ ", " group@ ", or " everyone@ ,
>> .IP \(bu
>> A
>> .BR user: " or " u:
>> prefix followed by a user name or user ID that designates a specific user,
>> .IP \(bu
>> A
>> .BR group: " or " g:
>> prefix followed by a group name or group ID that designates a specific group.
>> .RE
>> .PP
>> The entries are comma, whitespace, or newline separated.
>
> s/entries/fields of an ACL entry/ (?)

No, the fields in each of the different kinds of entries are colon separated.

"The ACL flags, file masks, and ACL entries are comma, whitespace, or newline
separated."

>> Flags and permissions have single-letter as well as long forms, as listed under
>> .IR "ACL flags" ,
>> .IR "ACL entry flags" ,
>> and
>> .IR Permissions .
>> When the single-letter forms are used, the flags or permissions are
>> concatenated. When the long forms are used, the flags or permissions are
>> separated by slashes.  To align permissions or flags vertically, dashes can be
>> used for padding.
>>
>> .SS Setting and modifying file permissions
>> The access permissions for a file can either be set by assigning an Access
>> Control List
>> .RB ( setrichacl (1))
>> or by changing the file mode permission bits
>> .RB ( chmod (1)).
>> In addition, a file can inherit an ACL from its parent directory at creation
>> time as described under
>> .IR "Permissions at file-creation time" .
>>
>> .SS Assigning an Access Control List
>> When assigning an ACL to a file, unless explicitly specified, the owner, group,
>> and other file masks will be computed from the ACL entries as described in
>> the section
>> .IR "Computing the maximum file masks" .
>> The owner, group, and other file mode permission bits are then each set from
>> the owner, group, and other file mask as follows:
>> .IP \(bu 2
>> If the file mask includes the
>> .B r
>> permission, the read
>> file mode permission bit will be set.
>> .IP \(bu
>> If the file mask includes the
>> .B w
>> or
>> .B p
>> permission, the write file mode permission bit will be set.
>> .IP \(bu
>> If the file mask includes the
>> .B x
>> permission, the execute file mode permission bit will be set.
>> .PP
>> If the ACL can be represented exactly by the file mode permission bits, the
>> file permission bits are set to match the ACL and no ACL is stored.  (When the
>> ACL of a file is requested which doesn't have an ACL, the file mode permission
>> bits are converted into an equivalent ACL.)
>>
>> .SS Changing the file mode permission bits
>> When changing the file mode permission bits with
>> .BR chmod (1),
>> the owner, group, and other file permission bits are set to the permission bits
>> in the new mode, and the owner, group, and other file masks are set based on
>> the new mode bits as follows:
>> .IP \(bu 2
>> If the read bit in a set of permissions is set, the
>> .B r
>> permission in the corresponding file mask will be set.
>> .IP \(bu
>> If the write bit in a set of permissions is set, the
>> .B w
>> and
>> .B p
>> permissions in the corresponding file mask will be set.
>> .IP \(bu
>> If the execute bit in a set of permissions is set, the
>> .B x
>> permission in the corresponding file mask will be set.
>> .PP
>> In addition, the
>> .B masked
>> and
>> .B write_through
>> ACL flags are set. This has the
>> effect of limiting the permissions granted by the ACL to the file mode
>> permission bits; in addition, the owner is granted the owner mode bits and
>> others are granted the other mode bits. If the
>> .B auto_inherit
>> flag is set, the
>> .B protected
>> flag is also set to prevent the Automatic Inheritance algorithm from modifying
>> the ACL.
>>
>> .SS Permissions at file-creation time
>> When a directory has any inheritable ACL entries, the following
>> happens when a file or directory is created inside that directory:
>> .RS 4
>
> Remove preceding line.
>
>> .IP 1. 4
>> A file created inside that directory will inherit all of the ACL entries that
>> have the
>> .B file_inherit
>> flag set, and all inheritance-related flags in the inherited entries flag will
>> be cleared.
>>
>> A subdirectory created inside that directory will inherit all of the ACL
>> entries that either have the
>> .B dir_inherit
>> flag set, or the
>> .B file_inherit
>> flag set and the
>> .B no_propagate
>> flag not set.  Entries whose
>> .B dir_inherit
>> flag is set will have their
>> .B inherit_only
>> flag cleared, and entries whose
>> .B dir_inherit
>> flag is not set will have their
>> .B inherit_only
>> flag set.  Finally, entries whose
>> .B no_propagate
>> flag is set will have all inheritance-related flags cleared.
>> .IP 2.
>> If the parent directory's ACL has the
>> .B auto_inherit
>> flag set, the inherited ACL will have its
>
> s/the/then the/
> (For ease of parsing)
>
>> .B auto_inherit
>> flag set, and all entries will have their
>> .B inherited
>> flag set.  Otherwise, the
>> .B auto_inherit
>> and
>> .B inherited
>> flags are cleared.
>> .IP 3.
>> The three file masks are computed from the inherited ACL as described in
>> the section
>> .IR "Computing the maximum file masks" .
>> .IP 4.
>> The three sets of permissions for the owner, the group, and for others in
>> the \fImode\fR parameter as given to
>> .BR open (2),
>> .BR mkdir (2),
>> and similar are converted into sets of RichACL permissions. The correspondence
>> between mask flags and RichACL permission bits is described in the section
>> .IR "Changing the file mode permission bits" .
>> Any RichACL permissions not included in those sets are
>> removed from the owner, group, and other file masks. The file mode permission
>> bits are then computed from the file masks as described in the section
>> .IR "Assigning an Access Control List" .
>> The process umask (see
>> .BR umask (2))
>> is ignored.
>> .IP 5.
>> The
>> .B masked
>> ACL flag is set. The
>> .B write_through
>> ACL flag remains cleared. In addition, if the
>> .B auto_inherit
>> flag of the inherited ACL is set, the
>> .B protected
>> flag is also set to prevent the Automatic Inheritance algorithm from modifying
>> the ACL.
>> .RE
>
> Remove preceding line.
>
>> .PP
>> When a directory does not have inheritable ACL entries, files and directories
>> created inside that directory will not be assigned Access Control Lists and the
>> file mode permission bits will be set to (\fImode\fR\ &\ ~\fIumask\fR) where
>> \fImode\fR is the mode argument of the relevant system call and \fIumask\fR is
>> the process umask (see
>> .BR umask (2)).
>>
>> .SS Automatic Inheritance
>> Automatic Inheritance is a mechanism that allows permission changes to
>> propagate from a directory to files and subdirectories inside that directory,
>> recursively.  Propagation is carried out by the process changing the directory
>> permissions (usually,
>> .BR setrichacl (1));
>> it happens without user intervention albeit not entirely automatically.
>>
>> A significant limitation is that this mechanism works only as long as files
>
> s/limitation/limitation of the Automatic Inheritance feature/
>
>> are created without explicitly specifying the file permissions to use. The
>> standard system calls for creating files and directories
>> .RB ( creat (2),
>> .BR open (2),
>> .BR mkdir (2),
>> .BR mknod (2))
>
> s/)$/,\nand so on)/
>
> (And, I'd drop creat(2) from that list of examples. It's ancient and
> obsolete; no need to encourageits use.)
>
>> all have mandatory mode parameters which define the maximum allowed permissions
>> of the new files. To take account of this restriction, the
>> .B protected
>> ACL flag must be set if the
>> .B inherited
>> flag is set. This effectively disables Automatic Inheritance for that
>> particular file.
>>
>> Notwithstanding the aforementioned limitation, Automatic Inheritance still
>> remains useful for network protocols like NFSv4 and SMB, which both support
>> creating files and directories without defining their permissions. These
>> protocols can implement those operations by using the standard system calls and
>> by then undoing the effect of applying the mode parameters.
>>
>> When the ACL of a directory is changed, the following happens for each entry
>> (\(lqchild\(rq) inside that directory:
>> .IP 1. 4
>> If the entry is a symbolic link, skip the child.
>> .IP 2.
>> If the
>> .B auto_inherit
>> flag of the entry's ACL is not set or the
>> .B protected
>> flag is set, skip the child.
>> .IP 3.
>> With the child's ACL:
>> .RS 4
>> .IP a) 4
>> If the
>> .B defaulted
>> flag is set, replace the ACL with an empty ACL
>> with the
>> .B auto_inherit
>> flag set.
>> .IP b)
>> Delete all entries which have the
>> .B inherited
>> flag set.
>> .IP c)
>> Append all entries inherited from the parent directory according to step 1 of
>> the algorithm described under
>> .IR "Permissions at file-creation time".
>> Set the
>> .B inherited
>> flag of each of these entries.
>> .IP d)
>> Recompute the file masks.
>
> At th end of the last section, add:
>
>         as descibed in the section "...."
>
>> .RE
>> .IP 4.
>> If the child is a directory, recursively apply this algorithm.
>>
>> .SS Access check algorithm
>>
>> When a process requests a particular kind of access (expressed as a set of
>> RichACL permissions) to a file, the following algorithm determines whether the
>> access is granted or denied:
>>
>> .IP 1. 4
>> If the
>> .B masked
>> ACL flag is set, then:
>> .RS 4
>> .IP a) 4
>> If the
>> .B write_through
>> ACL flag is set, then:
>> .RS 4
>> .IP \(bu 2
>> If the requesting process is the file owner, then access is granted if the
>> owner mask includes the requested permissions, and is otherwise denied.
>> .IP \(bu
>> If the requesting process is not the file owner and it is in the owning group or matches any ACL entries other than
>> .BR everyone@ ,
>> proceed to step b).
>> .IP \(bu
>> If the requesting process is not the file owner, is not in the owning group,
>> and no ACL entries other than
>> .B everyone@
>> match the process, then access is granted if the other mask includes the
>> requested permissions, and is otherwise denied.
>> .RE
>> .IP b)
>> If any of the following is true:
>> .RS 4
>> .IP \(bu 2
>> the requesting process is the file owner and the owner mask does not include all
>> requested permissions,
>> .IP \(bu
>> the requesting process is not the file owner and it is in the owning group or
>> matches any ACL entries other than
>> .BR everyone@ ,
>> and the group mask does not include all requested permissions,
>> .IP \(bu
>> the requesting process is not the file owner, not in the owning group, it
>> matches no ACL entries other than
>> .BR everyone@ ,
>> and the other mask does not include all requested permissions,
>> .PP
>> then access is denied.
>> .RE
>> .RE
>> .IP 2.
>> Upon reaching this point, the determination of whether or not access is granted
>> is made by scanning all ACL entries to see if one or more applicable entries
>> together grant a cumulative set of permissions that matches the requested
>> permissions or there is an applicable entry that explicitly denies one or more
>> of the requested permissions.  The scan of all ACL entries begins by first
>> initializing the set of remaining permissions (i.e., those that have not yet
>> been satisfied during the scan) to be the set of requested permissions. Then
>> the ACL entries are scanned
>> .IR "in order" ,
>> and for each entry:
>> .RS 4
>> .IP a) 4
>> If the
>> .B inherit_only
>> or
>> .B unmapped
>> flags are set, continue with the next ACL entry.
>> .IP b)
>> If any of the following is true:
>> .RS 4
>> .IP \(bu 2
>> the entry's identifier is
>> .B owner@
>> and the requesting process is the file owner,
>> .IP \(bu
>> the entry's identifier is
>> .B group@
>> and the requesting process is in the owning group,
>> .IP \(bu
>> the entry's identifier is a user and the requesting process is owned by that
>> user,
>> .IP \(bu
>> the entry's identifier is a group and the requesting process is a member in
>> that group,
>> .IP \(bu
>> the entry's identifier is
>> .BR everyone@ ,
>> .PP
>> then the entry matches the process; proceed to the next step. Otherwise,
>> continue with the next ACL entry.
>> .RE
>> .IP c)
>> If the entry denies any of the remaining permissions, access is denied.
>> .IP d)
>> If the entry allows any of the remaining permissions, then:
>> .RS 4
>> .IP \(bu 2
>> If the
>> .B masked
>> ACL flag is set and the entry's identifier is not
>> .B owner@
>> or
>> .BR everyone@
>> or is a user entry matching the file owner, remove all permissions from the
>> remaining permissions which are both allowed by the entry and included in the
>> group mask,
>> .IP \(bu
>> Otherwise, remove all permissions from the remaining permissions which are
>> allowed by the entry.
>> .RE
>> .RE
>> .IP 3.
>> If there are no more remaining permissions, access is allowed. Otherwise,
>> access is denied.
>> .PP
>> In this algorithm, a process can gain the permissions it requires by
>> accumulating them from multiple RichACL entries.  This is in contrast with
>> POSIX ACLs, where access is only granted if an ACL entry exists that matches
>> the requesting process and includes all the requested permissions.
>>
>> .SS Computing the maximum file masks
>> When setting an ACL and no file masks have been explicitly specified and when
>> inheriting an ACL from the parent directory, the following algorithm is used
>
> s/directory/directory (as described in section "....")/

Presumably "in the section" here as well.

>> for computing the file masks:
>>
>> .IP 1. 4
>> Clear the owner, group, and other file masks. Remember which permissions have
>> already been processed (initially, the empty set).
>> .IP 2.
>> For each ACL entry:
>> .RS 4
>> .IP \(bu 2
>> If the
>> .B inherit_only
>> flag is set, skip the entry.
>> .IP \(bu
>> Otherwise, compute which permissions the entry allows or denies that have not
>> been processed yet (the remaining permissions).
>> .IP \(bu
>> If the entry is an
>> .B owner@
>> entry, add the remaining permissions to the owner mask for
>> .B allow
>> entries, and remove the remaining permissions from the owner mask for
>> .B deny
>> entries.
>> .IP \(bu
>> Otherwise, if the entry is an
>> .B everyone@
>> entry, proceed as with
>> .B owner@
>> entries but add or remove the remaining permissions from the owner, group, and
>> other file masks.
>> .IP \(bu
>> Otherwise, proceed as with
>> .B owner@
>> entries but add or remove the remaining permissions from the owner and group
>> file masks.
>> .IP \(bu
>> Add the entry's permissions to the processed permissions.
>> .RE
>> .PP
>> The resulting file masks represent the ACL as closely as possible. With these
>> file masks, the effective permissions that the ACL grants will be the same when
>> the
>> .B masked
>> flag is set as when it is not set.
>>
>> .\" .SH BUGS
>> .SH AUTHOR
>> Written by Andreas Grünbacher <agruenba@redhat.com>.
>>
>> Please send your bug reports, suggested features and comments to the above address.
>>
>> .SH CONFORMING TO
>> Rich Access Control Lists are Linux-specific.
>> .SH SEE ALSO
>> .BR chmod (1),
>> .BR getrichacl (1),
>> .BR ls (1),
>> .BR setrichacl (1)
>> .BR stat (2),
>> .BR umask (2),
>> .BR acl (5)
>> .\" librichacl

[toc] | [prev] | [next] | [standalone]

#1340958

On Tue, Feb 23, 2016 at 4:09 PM, Andreas Gruenbacher
<agruenba@redhat.com> wrote:
> Hi Michael,
>
> On Tue, Feb 23, 2016 at 11:58 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> On 02/22/2016 03:46 PM, Andreas Gruenbacher wrote:
>>> On Sun, Feb 21, 2016 at 10:40 PM, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
>>>> I've once more pulled from the latest git; here's some more comments.
>>>
>>> thanks again. I've updated the repo with your changes.
>>
>> Next round :-). Just a few quick comments while I'm on a train ride.
>
> applied, thanks.

I've fixed the following additional problems:

> diff --git a/man/richacl.7 b/man/richacl.7
> index acdff31..1c82644 100644
> --- a/man/richacl.7
> +++ b/man/richacl.7
> @@ -30,10 +30,8 @@
>  .SH NAME
>  richacl \- Rich Access Control Lists
>  .SH DESCRIPTION
> -Rich Access Control Lists (RichACLs) are an extension of the POSIX file
> -permission model (see
> -.BR acl (5))
> -to support
> +Rich Access Control Lists (RichACLs) are an extension of the traditional POSIX
> +file permission model to support
>  .URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lists"
>  on local and remote-mounted filesystems.

RichACLs are an extension of the traditional POSIX file permission
model, not of the POSIX ACL model.

Unfortunately, there doesn't seem to be a man-page covering POSIX File
Access Permissions as in Appendix A of
http://www.bestbits.at/richacl/draft-gruenbacher-nfsv4-acls-in-posix-00.html.

A lot of the gaps between paragraphs were wrong when rendered for printing.

The modification dates were outdated.

Andreas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web