bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: acl: add support for MacOS X 10.5


From: Jim Meyering
Subject: Re: acl: add support for MacOS X 10.5
Date: Sat, 24 May 2008 09:25:12 +0200

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> Looks good.
>> You're welcome to commit regardless of the acl_trivial
>> issue mentioned below.
>
> Thanks, applied with a tweak (attached below) that should fix a probable
> breakage on IRIX in the original proposal.
>
>> Once you've investigated Solaris ACLs you might want to adjust that
>> comment.  I seem to recall seeing trivial ones with 4 or 5 entries.
>> ...
>> Have you considered using acl_trivial (also used in file-has-acl.c)
>> or a replacement that encapsulates this test?
>
> Haven't thought about it yet. Is it the syntactic or semantic triviality
> of the ACL which matters? (Example: If the file has the mode rwx------,

The goal in at least one place was to determine whether it was necessary
to copy the ACL.  Since naively testing n_entries is not effective with ZFS,
using acl_trivial seems like the only sensible approach; it does the right
thing, when it is available.  That it misses the corner case mentioned
in that bug report isn't a big deal for me.

> owner = 101, and an additional ACL "user:150:---", the ACL is semantically
> trivial: the additional ACL has no effect, since user 150 cannot access the

IMHO, it is not cp's (or copy_file's) job to determine semantic triviality.
It must copy any ACL that is not syntactically trivial.

> file anyway. But it's not syntactically trivial: 'ls' or getfacl displays it,
> and after the mode is changed to rwxrwx--- the additional ACL becomes
> effective.)
>
> Also, I'm not sure whether it's worth to use a function whose only known
> implementation (in Solaris) is buggy:
>   http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6664043




reply via email to

[Prev in Thread] Current Thread [Next in Thread]