2015-06-25 23:40 GMT+02:00 Stefan (metze) Metzmacher :
>>> I'm wondering if the size of an ace should be dynamic,
>>> which might make it possible to support other ace types
>>> in future. E.g. supporting other identities like 128-bit values
>>> to make it easier to map Windows SIDS.
>>
>> I'm work
Hi Andreas,
>> I'm wondering if the size of an ace should be dynamic,
>> which might make it possible to support other ace types
>> in future. E.g. supporting other identities like 128-bit values
>> to make it easier to map Windows SIDS.
>
> I'm working on additionally supporting unmapped user@do
Hi,
2015-06-25 21:58 GMT+02:00 Stefan (metze) Metzmacher :
> Is that also the on disk representation?
that's not the xattr representation, no.
> I'm wondering if the size of an ace should be dynamic,
> which might make it possible to support other ace types
> in future. E.g. supporting other ide
Hi Andreas,
> +#define RICHACE_OWNER_SPECIAL_ID 0
> +#define RICHACE_GROUP_SPECIAL_ID 1
> +#define RICHACE_EVERYONE_SPECIAL_ID 2
> +
> +struct richace {
> + unsigned short e_type;
> + unsigned short e_flags;
> + unsigned inte_mask;
> + union {
> + kuid_t
A richacl consists of an NFSv4 acl and an owner, group, and other mask.
These three masks correspond to the owner, group, and other file
permission bits, but they contain NFSv4 permissions instead of POSIX
permissions.
Each entry in the NFSv4 acl applies to the file owner (OWNER@), the owning
grou
5 matches
Mail list logo
