GNU bug report logs - #7708
cp: Solaris 11 ACL-related problem

Previous Next

Package: coreutils;

Reported by: Jim Meyering <jim <at> meyering.net>

Date: Wed, 22 Dec 2010 12:24:02 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-coreutils <at> gnu.org
Subject: cp: Solaris 11 ACL-related problem
Date: Wed, 22 Dec 2010 13:28:34 +0100
The cp/fail-perm test failed like this on solaris 5.11:

    ...
    cleanup_
    + :
    + cd /w/coreutils-8.7.78-628a6/tests
    + chmod -R u+rwx /w/coreutils-8.7.78-628a6/tests/gt-fail-perm.0bni
    + rm -rf /w/coreutils-8.7.78-628a6/tests/gt-fail-perm.0bni
    rm: cannot remove
    `/w/coreutils-8.7.78-628a6/tests/gt-fail-perm.0bni/DD/D':
    Permission denied
    + test 0 = 0
    + __st=1
    + exit 1

To see what's going on, I had to use the vendor ls's -v (show ACL) option:

$ /bin/ls -dv DD
drwxrwxrwx+  3 meyering meyering       3 Dec 22 02:48 DD
     0:owner@:read_attributes/write_attributes/read_acl/write_acl/synchronize
         :allow
     1:owner@:delete_child: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@::deny
     10:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/execute:allow
     11:everyone@:write_xattr/write_attributes/write_acl/write_owner:deny
     12:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

The culprit is the #1 rule; it denies owner dirent removal:

     1:owner@:delete_child:deny

Here's how that directory created:

    chmod g-s . || framework_failure
    mkdir D D/D || framework_failure
    touch D/a || framework_failure
    chmod 0 D/a || framework_failure
    chmod u=rx,go=,-st D || framework_failure

    # This is expected to exit non-zero, because it can't read D/a.
    cp -pR D DD > /dev/null 2>&1 && fail=1

The quick work-around is to remove all ACLs from ".":

      /bin/chmod -R A- .

But obviously we should not have to resort to that
in a test script.

Here's a small reproducer that should be made into its own test:
(the currently failing test does catch it, but it's almost by accident)

    $ mkdir -p D/D; chmod u=rx D; cp -pR D DD
    $ chmod -R 700 DD; rm -rf DD
    rm: cannot remove `DD/D': Permission denied
    [Exit 1]

Here's truss output from the above cp command:

    mkdir("DD/D", 0700)                             = 0
    lstat64("DD/D", 0x08047500)                     = 0
    openat(AT_FDCWD, "D/D", O_RDONLY|O_NDELAY|O_LARGEFILE) = 3
    fcntl(3, F_SETFD, 0x00000001)                   = 0
    fstat64(3, 0x080471B0)                          = 0
    getdents64(3, 0xCE9F4000, 8192)                 = 48
    getdents64(3, 0xCE9F4000, 8192)                 = 0
    close(3)                                        = 0
    utimensat(AT_FDCWD, "DD/D", 0x08047320, 0)      = 0
    lchown("DD/D", 14263, 14263)                    = 0
    pathconf("D/D", _PC_ACL_ENABLED)                = 2
    acl("D/D", ACE_GETACLCNT, 0, 0x00000000)        = 6
    stat64("D/D", 0x08047220)                       = 0
    acl("D/D", ACE_GETACL, 6, 0x0807FA00)           = 6
    stat64("DD/D", 0x080471C0)                      = 0
    pathconf("DD/D", _PC_ACL_ENABLED)               = 2
    acl("DD/D", ACE_SETACL, 7, 0x0807FA70)          = 0
    utimensat(AT_FDCWD, "DD", 0x080476A0, 0)        = 0
    lchown("DD", 14263, 14263)                      = 0
    pathconf("D", _PC_ACL_ENABLED)                  = 2
    acl("D", ACE_GETACLCNT, 0, 0x00000000)          = 6
    stat64("D", 0x080475A0)                         = 0
    acl("D", ACE_GETACL, 6, 0x0807EFF0)             = 6
    stat64("DD", 0x08047540)                        = 0
    pathconf("DD", _PC_ACL_ENABLED)                 = 2
    acl("DD", ACE_SETACL, 7, 0x0807F060)            = 0
    llseek(0, 0, SEEK_CUR)                          = 1314515
    close(0)                                        = 0
    close(1)                                        = 0
    close(2)                                        = 0
    _exit(0)

For the record, uname -a reports this:
  SunOS xxx 5.11 snv_134 i86pc i386 i86pc Solaris

I'm inclined to defer any fix until after the imminent release.




This bug report was last modified 13 years and 312 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.