Richacl and stored but ignored permissions

Richacl and stored but ignored permissions

[Steve French]

I noticed that setrichacl (on ext4/xfs with richacl patches from your
tree) allows setting some of the five "stored but ignored" permissions

S   synchronize
W  write named attributes
R  read named attributes
e write retention
E write retention hold

but it brings up some questions:
1) why is 'S' the only one of those five that although allowed to be
set, will not be displayed by getrichacl?  Presumably if it can be
set, you might as well display it on getrichacl and that might have
been the original intent since there is a space for it when you do
"getrichacl --full" but that implies (probably correctly) that
'Sychronize' permission is always granted.
2) should we allow 'e' and 'E' to be set (I lean toward yes, but NFS
rejected it when I tried, although xfs/ext4 accepted it).
3) Shouldn't we actually do something with 'W' (and maybe 'R'
permission but presumably that can be just implied to be on since some
attributes always need to be readable) and actually enforce use of W
permission to allow/forbid the setting of xattrs on the file?
4) Shouldn't we display as enabled permissions those that are implicit
rather than leaving them out (as if they are forbidden)?  e.g. the
'owner' permission ('o') presumably can be displayed for root (as it
is by default granted),  Also note the 'a' and 'S' permissions when
you do "getrichacl --full" are displayed as unset even though they are
implicitly granted.  You can fix that by setting 'a' explicitly but it
seems wrong to implicitly grant a permission, but not display it as
granted in getrichacl


-- 
Thanks,

Steve

Re: Richacl and stored but ignored permissions

[Andreas Gruenbacher]

Hi Steve,

On Tue, Nov 8, 2016 at 7:25 PM, Steve French <smfrench@gmail.com> wrote:
> I noticed that setrichacl (on ext4/xfs with richacl patches from your
> tree) allows setting some of the five "stored but ignored" permissions
>
> S   synchronize
> W  write named attributes
> R  read named attributes
> e write retention
> E write retention hold
>
> but it brings up some questions:
> 1) why is 'S' the only one of those five that although allowed to be
> set, will not be displayed by getrichacl?  Presumably if it can be
> set, you might as well display it on getrichacl and that might have
> been the original intent since there is a space for it when you do
> "getrichacl --full" but that implies (probably correctly) that
> 'Sychronize' permission is always granted.

the synchronize (S), read_attributes (a), and read_acl (c) permissions
are "always allowed". The read_named_attrs (R), write_named_attrs (W),
write_retention (e), and write_retention_hold (E) permissions have no
meaningful mapping locally. All of these permissions are stored but
ignored.

With setrichacl, when setting simple ACLs that can be fully
represented in the file permission bits, no actual ACL is stored. For
example, the ACL owner@:rwp::allow is stored as the rw------- file
permission bits. When checking if an ACL can be fully represented as
file permission bits, the "always allowed" permissions are ignored.
The ACL owner@:rwpS::allow (note the synchronize (S) permission) is
also stored as the rw------- file permission bits, and the synchronize
permission isn't explicitly preserved. This is likely why getrichacl
didn't seem to show the synchronize permission in your tests.

> 2) should we allow 'e' and 'E' to be set (I lean toward yes, but NFS
> rejected it when I tried, although xfs/ext4 accepted it).

Did you try with the appropriate NFS protocol version? These
permissions were added relatively late.

> 3) Shouldn't we actually do something with 'W' (and maybe 'R'
> permission but presumably that can be just implied to be on since some
> attributes always need to be readable) and actually enforce use of W
> permission to allow/forbid the setting of xattrs on the file?

The meaning of the R and W permissions is so vaguely defined that I
don't think it makes sense to map them to xattrs. Windows seems to use
them for something different than NFSv4 does according to
documentation, which may not even match what implementation do.

> 4) Shouldn't we display as enabled permissions those that are implicit
> rather than leaving them out (as if they are forbidden)?  e.g. the
> 'owner' permission ('o') presumably can be displayed for root (as it
> is by default granted), also note the 'a' and 'S' permissions when
> you do "getrichacl --full" are displayed as unset even though they are
> implicitly granted.  You can fix that by setting 'a' explicitly but it
> seems wrong to implicitly grant a permission, but not display it as
> granted in getrichacl

I've tried that, and things get confusing pretty fast:

 * The resulting ACLs were rather confusing.

 * What do you do with an ACL that doesn't have an entry for owner@ or the
   actual owner? Do you add an owner@ entry just to show the implicitly
   granted write_attributes (A) and write_acl (C) permissions?

 * Since you're mentioning the root user, should root entries be added as well?

 * Permissions might have to change when the file ownership changes, for entries
   representing the actual file owner.

* Would implicitly granted permissions be added to DENY ACEs as well?
   If not, will Windows still show DENY ACEs with well-known sets of
   permissions such as Full Access correctly?

Thanks,
Andreas

Re: Richacl and stored but ignored permissions

[Andreas Gruenbacher]

Steve,

please never cross-post to the samba-technical mailing list. It's a
members-only, unmoderated list, and whenever anybody who isn't a
member replies to an email that has samba-technical cross-posted, they
get a nasty mail delivery error:

550-Please subscribe the address agruenba@redhat.com to the samba-technical
550-mailing list before posting. See
<https://lists.samba.org/mailman/listinfo/samba-technical>.
550-You can also write a mail to samba-technical-owner@lists.samba.org and ask
550 to get on the list of accepted non-members to be able to send mail here.

Thanks,
Andreas