Re: coreutils-8.12.178-df9cd on Solaris 10

[Jim Meyering]

Bruno Haible wrote:
> Jim Meyering wrote:
>> >> You can probably find out by rerunning that test with e.g.,
>> >>
>> >>   SHELL=bash make check -C tests TESTS=cp/fail-perm VERBOSE=yes
>> > ...
>> > This is on an NFS volume.
>> >
>> If you rerun the test with the following patch to init.sh,
>> maybe it'll show us something interesting.
>> diff --git a/tests/init.sh b/tests/init.sh
>> index 12b3ca3..3bf5286 100644
>> --- a/tests/init.sh
>> +++ b/tests/init.sh
>> @@ -240,7 +240,7 @@ remove_tmp_ ()
>>    cleanup_
>>    # cd out of the directory we're about to remove
>>    cd "$initial_cwd_" || cd / || cd /tmp
>> -  chmod -R u+rwx "$test_dir_"
>> +  chmod --verbose -R u+rwx "$test_dir_"
>>    # If removal fails and exit status was to be 0, then change it to 1.
>>    rm -rf "$test_dir_" || { test $__st = 0 && __st=1; }
>>    exit $__st
>
> It still fails and shows:

Thank you.
I've narrowed the problem down to the fact that cp does not
copy ACLs faithfully on some OS/file-system combinations.
For example, on Solaris 10 with NFS (underlying FS is ZFS, I think),
this creates a directory, DD, that is not removable:

    mkdir -p D/x;chmod 500 D;cp -pR D DD;chmod -R 700 D*

My first clue was that "rm -rf D" worked fine, but not DD:

    $ rm -rf DD
    $ rm: cannot remove `DD/x': Permission denied
    $ ls -ld DD
    drwx--S---+ 3 meyering meyering 3 Sep  4 07:45 DD/

Recreate D, then list permissions of both:

    $ ls -ogd D*
    drwx--S---  3 3 Sep  4 08:18 D/
    drwx--S---+ 3 3 Sep  4 08:18 DD/
              ^
              |
That shows the difference.  DD has a "+" indicator, while D does not.
That little "+" indicates that DD has a non-default ACL,
which you can list with Solaris 10's /bin/ls -lv:

    $ /bin/ls -lv D DD
    D:
    total 1
    drwx--S---   2 meyering meyering       2 Sep  4 08:04 x
         0:owner@::deny
         1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
             /append_data/write_xattr/execute/write_attributes/write_acl
             /write_owner:allow
         2:group@:list_directory/read_data/add_file/write_data/add_subdirectory
             /append_data/execute:deny
         3:group@::allow
         4:everyone@:list_directory/read_data/add_file/write_data
             /add_subdirectory/append_data/write_xattr/execute/write_attributes
             /write_acl/write_owner:deny
         5:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow

    DD:
    total 1
    drwx--S---+  2 meyering meyering       2 Sep  4 08:04 x
         0:owner@:delete_child/read_attributes/write_attributes/read_acl
             /write_acl/synchronize:allow
         1:owner@::deny
         2:group@:delete_child/write_attributes/write_acl:deny
         3:group@:read_attributes/read_acl/synchronize:allow
         4:group@:delete_child/write_attributes/write_acl:deny
         5:everyone@:read_attributes/read_acl/synchronize:allow
         6:everyone@:delete_child/write_attributes/write_acl:deny
         7:owner@::deny
         8:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
             /append_data/write_xattr/execute/write_attributes/write_acl
             /write_owner:allow
         9:group@:list_directory/read_data/add_file/write_data/add_subdirectory
             /append_data/execute:deny
         10:group@::allow
         11:everyone@:list_directory/read_data/add_file/write_data
             /add_subdirectory/append_data/write_xattr/execute/write_attributes
             /write_acl/write_owner:deny
         12:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow

I don't expect to investigate/fix that before the release,
but at least did find a way finally to remove that directory.
Run this to grant rwx to $USER, and then removing works as expected:

    setfacl -muser:$USER:rwx DD