NFSv4 ACL support in star

[Edward Tomasz Napierała]

Wiadomość napisana przez Joerg Schilling w dniu 7 lis 2013, o godz. 12:10:
> Edward Tomasz Napiera?a <trasz at FreeBSD.org> wrote:
> 
>>> I like to see an implementation that (if implemented as an enhancement of the
>>> withdrawn POSIX.1e ACL interfaces) gives similar features as libsec does:
>> 
>> In order to make FreeBSD support NFSv4, I did exactly that: I've added
>> a number of functions, such as acl_get_entry_type_np(3) (basically, this
>> is for "allow/deny" part of ACL), and extended existing ones, e.g. to add
>> new permissions.
> 
> This looks like a missunderstanding:
> 
> I am not interested in single entries but in the currnt state of the acl_t 
> object.
> 
> acl_type(aclp) returns:
> 
> ACLENT_T = 0,	UFS ACLs (compatible with POSIX draft)
> ACE_T = 1	NFSv4 ACLs
> 
> I need to know whether to create
> 
> SCHILX.acl.access
> and
> SCHILY.acl.default
> 
> keywords or 
> 
> SCHILY.acl.ace
> 
> before I convert things and I don't like to parse the text...

Okay, so this is what acl_get_brand_np() is for.  The acl_get_entry_type_np()
returns NFSv4 entry type, i.e. whether it's "allow", or "deny".

>>> -	libsec e.g. calls pathconf(name, _PC_ACL_ENABLED) in order to find
>>> 	the ACL type that is used for a file and controls which ACL flavor to 
>>> 	retrieve.
>> 
>> Use the usual pathconf(3), with _PC_ACL_NFS4.
> 
> This looks like an interface that is not optimized for performance.
> 
> pathconf(name, _PC_ACL_ENABLED)
> 
> returns
> 
> _ACL_ACLENT_ENABLED	(1)	if the filesystem supports UFS ACLs
> _ACL_ACE_ENABLED	(2)	if the filesystem supportfs NFSv4 ACLs
> 
> or a bitwise or of both.
> 
> But if you implement another performant method I am OK. 

As Tim said, you probably already need to call stat on every file
added; just reuse the value returned by pathconf if st_dev for the
file is the same as st_dev for the previous file.  That's what all
the utilities such as ls(1) do

>>> -	libsec includes code to deal with ephemeral IDs used with CIFS clients.
>> 
>> Hm, isn't this independent from ACL implementation?
> 
> It may look so but there are related ACE entries and these ACEs carry ephemeral 
> UID/GID values.

Ah, the appended ID.  So, acl_to_text_np(3) takes ACL_TEXT_APPEND_ID flag,
which makes it output textual form with appended IDs; the acl_from_text(3)
handles appended ID automatically.

>>> -	libsec offers acl_type(aclp) to find the ACl type without a need to
>>> 	call acl_totext(), so I could use:
>> 
>> See acl_get_brand_np().
> 
> OK, this is what I am interested in.

Ok.

>>> I am in hope that we could get a final library interface that still stays 
>>> compatible between FreeBSD and Linux as this was the base for being able to 
>>> support more platforms with POSIX.1e draft ACLs.
>> 
>> I think porting what I did would be a good choice - it's fully backwards
>> compatible, API-wise, and not actually hacky.
> 
> Well, it would be nice to see feedback from Linux people.

Definitely.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?