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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Meyering <jim <at> meyering.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#7708: closed (cp: Solaris 11 ACL-related problem)
Date: Tue, 13 Sep 2011 15:22:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 13 Sep 2011 17:17:01 +0200
with message-id <87mxe8zd3m.fsf <at> rho.meyering.net>
and subject line Re: bug#7708: cp: Solaris 11 ACL-related problem
has caused the debbugs.gnu.org bug report #7708,
regarding cp: Solaris 11 ACL-related problem
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
7708: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7708
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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.

[Message part 3 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: 7708-done <at> debbugs.gnu.org
Subject: Re: bug#7708: cp: Solaris 11 ACL-related problem
Date: Tue, 13 Sep 2011 17:17:01 +0200

Jim Meyering wrote:
> Jim Meyering wrote:
> ...
>> 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)
...

Closing this.
Thanks to Bruno's work in gnulib, the problem is solved.

Previous Next

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