Hi Michael,

On Sun, Feb 7, 2016 at 5:35 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

Hi Andreas,

I'll probably have quite a few more comments on this page as I get to
understand RichACLs better. Here's some comments from an initial
reading.

thanks a lot for all the feedback to the man-pages. I've more or less
made all the suggested changes but didn't get to adding examples yet
(that's not so easy).

The changes are here:

  https://github.com/andreas-gruenbacher/richacl

So, an initial comment. It seems to me to that this page (but
not setrichacl(1) and getrichacl(1)) should ultimately land in
man-pages (just like acl(7)), since we're talking about a kernel
feature. Make sense?

We could sure move acl(5) and richacl(7) there.

quoted

.\"
.\" Richacl Manual Pages
.\"
.\" Copyright (C) 2015  Red Hat, Inc.
.\" Written by Andreas Gruenbacher [off-list ref]
.\" 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

For what it's worth, I think it would be worthwhile to start with
a consistent abbreviation comment here (and use it throughout all of the
man pages): "RichACL" (or "richACL"), rather than "richacl"; that seems
more consistent with the traditional abbreviation "ACL".

quoted

permission model to support

Make this:

permission mode (see
.BR acl (7))
to support

quoted

.URL https://tools.ietf.org/rfc/rfc5661.txt "NFSv4 Access Control Lists"
on local and remote-mounted filesystems.

Richacls support file masks which allow to apply a file mode to an existing

s/which allow to apply/which can be used to apply/

quoted

NFSv4 ACL without destructive side effects: the file mode determines the values
of the file masks; the file masks restrict the permissions granted by the NFSv4
ACL.  When a less restrictive file mode is applied later, the file masks become
less restrictive, and more of the original permissions can become effective.

A richacl can always be translated into an equivalent NFSv4 ACL which grants
the same permissions.

Richacls can be enabled on supported filesystems. This disables POSIX Access
Control Lists; the two ACL models will not coexist on the same filesystem.

s/will not/can not/ ?

quoted

When used on a filesystem that does not support richacls, the getrichacl and

Use
.BR getrichacl (1)
for cross-references.

quoted

setrichacl utilities will operate on the file permission bits instead:
getrichacl will display the file permission bits as a richacl; when a richacl

Use
.BR getrichacl (1)
for cross-references.

quoted

is set with setrichacl which can be represented exactly by the file permission

Use
.BR setrichacl (1)
for cross-references.

quoted

bits, setrichacl will set the file permission bits instead.

Use
.BR setrichacl (1)
for cross-references.

Here, I think it would be helpful to add a sentence:

"An attempt to set a richacl that cannot be represented exactly by the
file permission bits results in an error."

(If that sentence is correct, of course.)

quoted

.SH STRUCTURE OF RICHACLS

For all of the "nonstandard" (see man-pages(7)) ".SH" sections here, I'd
be inclined to switch to using ".SS" subsections. There are downsides to
multiple nonstandard section headings (e.g., automated TOCs for
Section headings become clumsy and long), and I don't think your use of
.SH vs .SS really helps much to structure the information in this page.

quoted

Richacls consist of a number of ACL entries, three file masks, and some flags.

s/some flags./some flags specifying attributes of the ACL as whole (by
contrast with the per-ACL-entry flags described below)./

quoted

Each of the ACL entries allows or denies some permissions to a particular user,
group, or special entity. Each acl entry consists of:

s/acl//

quoted

.IP \(bu 4
The user (with prefix

s/The user/A tag which specifies the user/

(Is "tag" the right word? In any case, what would helpful to have here
is the generic term for this component of the ACL.)

Tag should do; I'm not aware of a better term.

quoted

.B user:
or
.BR u: ),
group (with prefix
.B group:
or
.BR g: ),
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 4
A field indicating whether the entry allows or denies access.
.PP
The owner, group, and other file masks further control which permissions the
ACL grants, subject to the
.B masked
.RB ( m )
and
.B write_through
.RB ( w )
ACL flags.

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
owner, are not in the owning group, and do not match a user or group mentioned
in the acl.

s/acl/ACL/

quoted

Richacls do not have separate \(lqaccess\(rq ACLs that define the access
permissions and \(lqdefault\(rq ACLs that define the inheritable permissions as
POSIX ACLs.

I'd restructure the preceding sentence as:

"Unlike POSIX ACLs, richacls do not.... that define the inheritable
permissions."

quoted

Instead, whether an ACL entry is effective during access checks
and/or inheritable is determined by the ACL entry flags.

.SS ACL Flags

I'd use lower case in the above for all words except the first.
(That's the convention in man-pages.)

quoted

The following flags on ACLs are defined:

.RS 4
.HP 4

s/4/8/ in the preceding two lines. I think more indentation would make
this (and the similar lists below) more readable.

quoted

.B masked
.RB ( m ):

I'd write each of these list entries starting here, and below, in the
form:

.BR masked "\ (" m ):

This form is a little easier to read in the source, and
it forces just a single space before the "(", which looks
a little better, I find.

quoted

When set, the file masks define upper limits on the permissions the ACL may
grant.
.HP
.B write_through
.RB ( w ):
When this flag and the masked flag are both set, the owner and other file masks

.B masked

quoted

define the actual permissions granted to the file owner and to others instead
of an upper limit.
.HP
.B auto_inherit
.RB ( a ):
Automatic Inheritance is enabled for the file the ACL is
attached to. See
.IR "Automatic Inheritance" .
.HP
.B protected
.RB ( p ):
The ACL is protected from modification by Automatic
Inheritance.
.HP
.B defaulted
.RB ( d ):
The ACL has been assigned by default. Automatic Inheritance should completely
replace the ACL.
.RE

.SS ACL Entry Flags

The following flags on ACL entries are defined:

.RS 4
.HP 4

s/4/8/ in the preceding two lines.

quoted

.B file_inherit
.RB ( f ):
The entry is inheritable for files.
.HP
.B dir_inherit
.RB ( d ):
The entry is inheritable for directories.
.HP
.B no_propagate
.RB ( n ):
Inheritance stops at the next subdirectory level.
.HP
.B inherit_only
.RB ( i ):
The entry defines inheritable permissions only and is ignored for access
checking.
.HP
.B inherited
.RB ( a ):
The entry has been automatically inherited from the parent directory; the
ACL's auto_inherit

Use
.B auto_inherit

quoted

.RB ( a )
flag should be on.
.HP
.B unmapped
.RB ( u ):
The user or group identifier is a textual string and has no mapping to a
numeric user or group identifier.

So here, I think there should be a sentence that explains how a meaning
is attached to the strings? Is this for NFS, for Windows, for something
else?

On NFS clients only. I've tried to clarify that.

quoted

.RE

.SS Permissions

The following permissions are defined for richacl entries and for the three
file masks:

.RS 4
.HP 4

s/4/8/ in the preceding two lines.

quoted

.B read_data
/
.B list_directory
.RB ( r ):

Replace the preceding four lines by

.BR read_data / list_directory "\ (" r )

and do similar for the next two list entried below.
Note that "\ (" will force just a singlke space before the "(".

quoted

Read the data of a file.
List the contents of a directory.

In the above list entry, and the next two, I find the layout ("xxx/yyy (z)")
confusing. A closer reading indicates that in each case, the "xxx"
applies for files and he "yyy" is for directories. But I think the text
could make this point a little easier to grasp. In each of these three
list entries this could be done something lke the following:

"For a file: read the data of the file. For a directory: list the
contents of the directory."

By the way, can the terms "read_data" and "list_directory" be used
interchangeably? That is, can you employ (say) "read_data" when setting
an ACL entry for a directory? (I'm assuming the answer is "yes".)
If the terms are just interchangeable synonyms, perhas it's worth
making that point explicitly in the text.

richacl_from_text() doesn't distinguish between file and directory
flags, but richacl_to_text() will use the appropriate version in
long-format strings depending on the context (file type). ACLs that
have this wrong would be very confusing to read.

quoted

.HP
.B write_data
/
.B add_file
.RB ( w ):
Modify the data of a file. Add a new file in a directory.

See above comment re file/directory.

quoted

.HP
.B append_data
/
.B add_subdirectory
.RB ( p ):
Open a file in append mode. Create a subdirectory in a directory.

So, in other words, if append mode is denied, then the file can be
opened for writing (contingent on write permission  being granted), but
can't be opened with O_APPEND? Is that correct? This point needs to be
made clearer.

Yes, that's correct.

quoted

.HP
.B execute
.RB ( x ):
Execute a file. Traverse / search a directory.

See above comment re file/directory.

quoted

.HP
.B delete_child
.RB ( d ):
Delete a file or directory within a directory.
.HP
.B delete
.RB ( D ):
Delete the file or directory.
.HP
.B read_attributes
.RB ( a ):
Read basic attributes of a file or directory.

What are "attributes" in this context? Does this mean stat(2)? Make this
explicit.

Yes.

quoted

This permission is always implicitly granted.
.HP
.B write_attributes
.RB ( A ):
Change the times associated with a file or directory to an arbitrary value.
This permission is always implicitly granted to the file owner.
.HP
.B read_acl
.RB ( c ):
Read the ACL of a file or directory. This permission is always
implicitly granted.
.HP
.B write_acl
.RB ( C ):
Change the ACL or file mode of a file or directory.
.HP
.B write_owner
.RB ( 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.
.HP
.B read_named_attrs
.RB ( R ),
.B write_named_attrs
.RB ( W ),
.B synchronize
.RB ( S ),
.B write_retention
.RB ( e ),
.B write_retention_hold
.RB ( E ):
These permissions can be stored, but do not have a local meaning.

So, I thenk that a sentence here should explain why these permissions
exist. Is if for future extension, because they are meaningful in NFS,
or something else?

Yes, they are defined by NFS.

quoted

.RE

.SH TEXT FORM

The common textual representation of richacl consists of the colon separated

s/richacl/richacls/ (or, "RichACLs"/"richACLs")

s/colon separated/colon-separated/

quoted

fields of the the acl flags, file masks, and acl entries in the following

s/acl/ACL/ (*2)

quoted

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 whether the entry allows or denies permissions.  The who field has

s/who/\\fIwho\\fP/

quoted

no prefix for special identifiers, a
.B user:
or
.B u:
prefix for regular users, and a
.B group:
or
.B g:
prefix for regular groups.
.PP
The entries are comma, whitespace or newline separated.

s/whitespace/whitespace,/

quoted

Flags and permissions have single-letter as well as long forms as listed under

s/forms/forms,/

quoted

.IR "ACL Flags" ,
.IR "ACL Entry Flags" ,
and
.IR Permissions .

If you follow my suggestion about capitalization in the ".SS" entries,
you'll need to change the capitalization in the above phrases.

quoted

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
use for padding.

s/use/used/

quoted

.SH SETTING AND MODIFYING FILE PERMISSIONS
The access permissions for a file can either be set by assigning an access
control list (setrichacl) or by changing the file mode permission bits (chmod).

Use
.RB ( setrichacl (1))
for cross-reference.

Use
.RB ( chmod (1)).

quoted

In addition, a file can inherit an ACL from its parent
directory at create time; the inherited ACL is then further

s/create/creation/

quoted

restricted by the creating system call's mode parameter (see the creat(2)
manual page).

creat(2) is pretty much history. I suggest writing

(as given to
.BR open (2),
.BR mkdir (2),
and similar).

And here, I think we need a statement about whether the process umask
has an effect or not...

quoted

.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
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 4
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 access control
list and the ACL is not stored.  (When the reverse happens and

s/and/and the/

quoted

ACL of a file is requested which doesn't have an explicit
ACL, the file mode permission bits are converted into an
equivalent richacl.)

.SS Changing The File Mode Permission Bits

I'd use lower case in the above for all words except the first

quoted

When changing the file mode permission bits with chmod(2), the owner, group,

.BR chmod (2)

quoted

and other file permission bits are set to the permission bits in the new mode,
and the file masks each are set based on the new mode bits as follows:
.IP \(bu 4
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 Create Time

s/File Create/file-creation/

I'd use lower case in the above for all words except the first

quoted

When a directory has inheritable ACL entries, the following
happens when a file or directory is created inside that directory:
.RS 4
.IP 1. 4
A file created inside that directory will inherit all entries with the

s/all entries with/all of the directories entries that/

It's ACL entries, not directory entries, here.

quoted

.B file_inherit
flag set, and all inheritance-related flags in the inherited entries will be
cleared.

A subdirectory will inherit all entries with the
.B file_inherit
or
.B dir_inherit
flag set.  Entries whose
.B no_propagate
flag is set will have all inheritance-related flags cleared.  Entries whose
.B no_propagate
and
.B dir_inherit
flags are not set and whose
.B file_inherit
is set will have their
.B inherit_only
flag set.
.IP 2.
If the parent directory's ACL has the
.B auto_inherit
flag set, the inherited ACL will have its
.B auto_inherit
flag set, and all entries will have their
.B inherited
flag set.
.IP 3.
The three file masks are computed from the inherited ACL as described in
section
.IR "COMPUTING THE MAXIMUM FILE MASKS" .
.IP 4.
The three sets of permissions for the owner, the group, and for others in
the mode parameter of the creating system call are converted into sets of
richacl permissions as described in section

s/in/in the/

quoted

.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 section

s/in/in the/

quoted

.IR "Assigning An Access Control List" .
.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
.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 (mode\ &\
~umask).

will be set to

    (mode & ~umask)

where
.I mode
is the permission mode argument of the relevant system call and
.I umask
is the process umask (see
.BR umask (2)).

quoted

.SS Automatic Inheritance

I'd use lower case in the above for all words except the first

"Automatic Inheritance" is a technical term though.

quoted

Automatic Inheritance allows permission changes to propagate from a directory
to files and subdirectories inside that directory, recursively.  Carrying out
this propagation of permissions is the responsibility of the process changing
the directory permissions (usually, setrichacl(1)).

I'm confused by the previous sentence. the feature is labeled "Automatic
Inheritance", implying that the user/process need do nothing. The next
sentence says "propagation ... is the responsibility of the process".
These two points seem contradictory. I think something more needs to be
said here.

Let's try this maybe:

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.

quoted

A significant limitation is that this mechanism works only as long as files
are created without explicitly specifying the file permissions to use. The
standard system calls for creating files an directories (creat(2), open(2),
mkdir(2), mkfifo(2), mknod(2)) all have mandatory mode parameters which define

Format that system call list as
.RB ( creat (2),
.BR open (2),
.BR mkdir (2),
.BR mknod (2))

Note that I removed mkfifo(): it's a library functionlayered on
mkonod(2).

quoted

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.

Automatic Inheritance still remains useful for network protocols like NFSv4 and
SMB, which both support creating files and directories without defining which
permissions: they 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 should

Why "should"?

quoted

happen for each entry inside that directory (for each \(lqchild\(rq):

Make the preceding line:

happen for each entry (\(lqchild\(rq) inside that directory:

quoted

.IP 1. 4
If the entry is a symblic 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 1. 4

s/1./a)/

(i.e., use a different labeling scheme for the sublist)

quoted

If the
.B defaulted
flag is set, replace the ACL with an empty ACL
with the
.B auto_inherit
flag set.
.IP 2.

s/2./b)/

quoted

Delete all entries which have the
.B inherited
flag set.
.IP 3.

s/3./c)/

quoted

Append all entries inherited from the parent directory according to step 1 of
the algorithm described under
.IR "Permissions At File Create Time".
Set the
.B inherited
flag of each of these entries.
.IP 4.

s/4./d)/

quoted

Recompute the file masks.
.RE
.IP 4.
If the child is a directory, recursively apply this algorithm.

.SH ACCESS CHECK ALGORITHM

When a process requests a particular kind of access to a file defined by a set

s/defined/protected/ (?)

quoted

of richacl permissions, the following algorithm determines if the access is

s/if/whether/

quoted

granted or denied:

.IP 1. 4
If the
.B masked
ACL flag is set, then:
.RS 4
.IP 1. 4

s/1./a)/

Use a different numbering scheme for sublists.

quoted

if the

s/if/If/

quoted

.B write_through
ACL flag is set, then:
.RS 4
.IP \(bu 4
if the requesting process is the file owner, then access is granted if the

s/if/If/

quoted

owner mask includes the requested permissions, and is otherwise denied.
.IP \(bu
if the requesting process is not the file owner, is not in the owning group,

s/if/If/

quoted

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 2.

s/2./b)/

quoted

if any of the following is true:

s/if/If/

quoted

.RS 4
.IP \(bu 4
the requesting process is the file owner and the owner mask does no include all

s/no /not /

quoted

requested permissions,
.IP \(bu 4
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 no include all requested permissions,
.IP \(bu 4
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 no include all requested permissions,
.PP
then access is denied.
.RE
.RE
.IP 2.
Set the remaining permissions to the requested permissions.  Go through all ACL
entries. For each entry:
.RS 4
.IP 1. 4

s/1./a)/

Use a different numbering scheme for sublists.

quoted

if the
.B inherit_only
or
.B unmapped
flags are set, continue with the next ACL entry.
.IP 2.

s/2./b)/

quoted

if any of the following is true:
.RS 4
.IP \(bu 4
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
the entry matches the process; proceed. Otherwise, continue with the next ACL

s/proceed/proceed to the next step/  (?)

quoted

entry.
.RE
.IP 3.

s/3./c)/

quoted

If the entry denies any of the remaining permissions, access is denied.
.IP 4.

s/4./d)/

quoted

If the entry allows any of the remaining permissions, then:
.RS 4
.IP \(bu 4
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 wich are
allowed by the entry.
.RE
.RE
.IP 3.
If there are no more remaining permissions, access is allowed. Otherwise,
access is denied.

.SH 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
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 4
If the
.B inherit_only
flag is set, skip the entry.
.IP \(bu 4
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, if the
.B masked
ACL flag is set, the effective permissions still stay the same.

This page is in *desperate* need of *multiple* examples, starting simple,
and building up in complexity, with walkthogh text explaining how the
permisssions are interpreted and how the masks are generated.
Having read the page multiple times (and having little knowledge
of NFS ACLs), I'm still struggling to put all the pieces together.

You are probably right. I'm not sure if they should go on the same man-page.

Probably some examples that relate to an NFS context would also be
helpful.

Hmm, I'm not sure about the difference between NFS examples and
non-NFS examples I suppose.

quoted

.\" .SH BUGS
.SH AUTHOR
Written by Andreas Grünbacher [off-list ref].

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 (7)
.\" librichacl

Thanks a lot,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html