Hi Steve,
On Tue, Nov 8, 2016 at 7:25 PM, Steve French <smfrench@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
