Re: ACL support.

[Edward Shishkin <edward.shishkin@gmail.com>]

On 04/08/2014 08:28 PM, Daniel Horne wrote:
> On 26 March 2014 10:34, Edward Shishkin <edward.shishkin@gmail.com
> <mailto:edward.shishkin@gmail.com>> wrote:
>
>     On 03/26/2014 06:23 AM, dE wrote:
>
>         Does reiser4 support ACL?
>
>
>     Nope for historical reasons.
>     I'll provide hints how to implement this, if someone wants..
>
>
> I occasionally have a look at making an XATTR implementation before
> getting sidetracked.
>
> There's a couple of points I'm not quite decided on:
>
> Whether to make a generic xattr stat_data plugin and use it to store all
> different types of attribute, or make different plugins for ACL, SElinux
> contexts, and user xattrs.
>
> You've previously stated that stat_data plugins are limited to 4k. This
> should be fine for selinux contexts and all but pathologically long
> access control lists, I'm not sure about the use of user xattrs. Would
> making separate stat_data plugins give separate 4k limits to each type
> of attribute, or is that all-inclusive?
>


Actually stat-data is an on-disk container of inode fields. That said, I 
would prefer to store xattrs in special items, which are different from 
stat-data (one such item per a pair (xattr_name, xattr_value)).


> There's also the matter of choosing an on-disk format. A simple list
> format, perhaps? Lookup would be O(n), but given the small amount of
> data we're expecting to store there, that may be OK.

I suggest that we use the following format for the xattr items.

The key of the item associated with the pair (xattr_name, xattr_value) 
is [base_key, offset], where base_key is calculated by build_xattr_key()
(not yet implemented). This function does mostly the same as 
build_sd_key(). The difference is that build_xattr_key() installs
a special reserved (and currently not used) minor locality 
KEY_ATTR_NAME_MINOR (see key.h for the definition).

64-bit key offset is composed of 32-bit major_offset and 32-bit minor 
offset. Major offset is a 32-hash of the xattr_name. Minor offset is the 
number of the collision in the chronology ordering.

Format of the item body is the following:
. size-of-xattr_name (16 bit)
. xattr_name;
. xattr_value

So getxattr(2) is resolved to the following actions:

. build base_key for the xattr_name;
. set major offset as hash(xattr_name);
. linear search for precise xattr_name among all items with the same 
[key_base, major_offset].
. return respective xattr_value (or NOT_FOUND).

setxattr(2) is resolved to the following actions:

. compose the item body in accordance with the format above;
. build base_key for xattr_name;
. set the major offset, i.e. hash(xattr_name);
. search for the xattr_name among all items with the same [base_key, 
major_offset];
. update the item body, or (depending on the flags) return EEXIST, if 
the item with xattr_name was found;
. set the respective minor_offset by the search results, if the item 
with xattr_name was not found;
. insert the new item with the [base_key, offset] to the current 
position in the tree.

For simplicity and performance reasons let's assume that xattr items are 
solid. That said, any xattr item contains exactly one unit. In 
particular, it means that sizeof(xattr_name + xattr_value) can not 
exceed 4096 - (sizeof(node_header) + sizeof(item_header)). Let's 
implement xattrs support with such restrictions for now. Also, don't 
update minor offsets of colliding items when removing xattr: I don't 
think that we'll exceed the limit for the number of collisions (2^32)
in the foreseeable future.

Makes sense?
Let me know if any problems..

Thanks,
Edward.