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