[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17669: Fwd: Re: Solaris acl woes
From: |
Ben Walton |
Subject: |
bug#17669: Fwd: Re: Solaris acl woes |
Date: |
Tue, 3 Jun 2014 21:25:06 +0100 |
On Tue, Jun 3, 2014 at 7:27 PM, Pádraig Brady <address@hidden> wrote:
> On 06/03/2014 07:07 PM, Ben Walton wrote:
>>
>> On Jun 3, 2014 11:22 AM, "Pádraig Brady" <address@hidden
>> <mailto:address@hidden>> wrote:
>>>
>>> On 06/03/2014 07:51 AM, Ben Walton wrote:
>>> > On Jun 2, 2014 6:46 PM, "Paul Eggert" <address@hidden
>>> > <mailto:address@hidden>> wrote:
>>> >>
>>> >> [Forwarding this to Bug#17669 as bug-coreutils seems to have misfiled it
>>> > under 17664; closing 17664.]
>>> >>
>>> >> -------- Original Message --------
>>> >> Subject: Re: Solaris acl woes
>>> >> Date: Mon, 02 Jun 2014 06:56:03 -0700
>>> >> From: Paul Eggert <address@hidden <mailto:address@hidden>>
>>> >> Organization: UCLA Computer Science Department
>>> >> To: Ben Walton <address@hidden <mailto:address@hidden>>,
>>> >> address@hidden <mailto:address@hidden>,
>>> > address@hidden <mailto:address@hidden>
>>> >>
>>> >>
>>> >>
>>> >> Ben Walton wrote:
>>> >>
>>> >>> The lib/file-has-acl.c:acl_ace_nontrivial code that returns 1 is:
>>> >>
>>> >>
>>> >> Why is it returning 1, exactly? What are the value of access_masks[0,
>>> >> 1] and how do they compare to the masks, and what bits are set that
>>> >> shouldn't be if we want the ACLs to be trivial?
>>> >
>>> > I didn't get back to this yesterday but will tonight.
>>> >
>>> > What do you think about the fact that the Solaris tools seem to exhibit
>>> > the
>>> > same behavior?
>>>
>>> I'd probably adjust the tests to first:
>>>
>>> getfacl test.acl | setfacl -f - test.acl || skip_ "system is unable to copy
>>> ACLs"
>>>
>>
>> Not a bad idea, but those tools have different names on different systems
>> and possibly different calling conventions.
>>
>> If this is a preferred approach, at the very least, a presence check for the
>> binary needs to wrap the precondition.
>
> We already have that in require_acl_
> Though yes it's very awkward that there is no standard here.
> This is how one copies ACLs on the systems I've just checked:
>
> solaris: getfacl file1 | setfacl -f - file2
> linux: getfacl file1 | setfacl --set-file=- file2
> freebsd: getfacl file1 | setfacl -b -n -M - file2
>
> So not ideal at all.
Ok, let me see what I can bang together. I vaguely recall seeing other
code that was doing something along these lines so I might be able to
find a useful reference to start from.
>
> Which 6 tests did this affect BTW?
FAIL: tests/cp/backup-dir
cp -a
FAIL: tests/cp/cp-parents
cp -a
FAIL: tests/cp/parent-perm-race
cp --preserve=mode
FAIL: tests/cp/preserve-link
cp -a
FAIL: tests/cp/reflink-perm
cp --preserve
FAIL: tests/cp/src-base-dot
cp -a
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself. Much more happiness,
truth, beauty and wisdom will come to you that way.
-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
- bug#17669: Solaris acl woes, Ben Walton, 2014/06/02
- bug#17664: Solaris acl woes, Paul Eggert, 2014/06/02
- bug#17669: Fwd: Re: Solaris acl woes, Paul Eggert, 2014/06/02
- bug#17669: Fwd: Re: Solaris acl woes, Ben Walton, 2014/06/03
- bug#17669: bug#17664: bug#17669: Fwd: Re: Solaris acl woes, Paul Eggert, 2014/06/03
- bug#17669: Fwd: Re: Solaris acl woes, Pádraig Brady, 2014/06/03
- bug#17669: Fwd: Re: Solaris acl woes, Paul Eggert, 2014/06/03
- bug#17669: Fwd: Re: Solaris acl woes, Ben Walton, 2014/06/03
- bug#17669: Fwd: Re: Solaris acl woes, Pádraig Brady, 2014/06/03
- bug#17669: Fwd: Re: Solaris acl woes,
Ben Walton <=