Re: coreutils-8.12.178-df9cd on Solaris 10

[Bruno Haible]

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

Indeed, I reproduce it too:

$ mkdir D D/D
$ /bin/ls -lvd D
drwxrwxr-x   3 haible   haible         3 Sep  4 16:15 D
     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@::deny
     3:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/execute:allow
     4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

$ chmod u=rx,go=,-st D
$ /bin/ls -lvd D
dr-x------   3 haible   haible         4 Sep  4 16:15 D
     0:owner@:add_file/write_data/add_subdirectory/append_data:deny
     1:owner@:list_directory/read_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

$ ./cp -pR D DD
$ /bin/ls -lvd DD
dr-x------   3 haible   haible         3 Sep  4 16:15 DD
     0:owner@:list_directory/read_data/execute/read_attributes
         /write_attributes/read_acl/write_acl/synchronize:allow
     1:owner@:add_file/write_data/add_subdirectory/append_data/delete_child
         :deny
     2:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/execute/delete_child/write_attributes/write_acl:deny
     3:group@:read_attributes/read_acl/synchronize:allow
     4:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/execute/delete_child/write_attributes/write_acl:deny
     5:everyone@:read_attributes/read_acl/synchronize:allow
     6:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/execute/delete_child
         /write_attributes/write_acl:deny

It's here that the 'delete_child' operation for the owner was denied.
IMO it's correct: 'delete_child' is handled like 'add_subdirectory'.

$ chmod 700 D DD
$ /bin/ls -lvd DD
drwx------+  3 haible   haible         3 Sep  4 16:15 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@: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

Here it remains denied. Although 'add_subdirectory' is allowed.
An strace of what the chmod command does:

$ truss /bin/chmod 700 DD
lstat64("DD", 0x000243A0)                       = 0
chmod("DD", 0700)                               = 0
pathconf("DD", _PC_ACL_ENABLED)                 = 2

Or with GNU chmod:

$ truss ./chmod 700 DD
stat64("DD", 0x00040EE0)                        = 0
chmod("DD", 0700)                               = 0

So, in summary, there are two problems:
  - 'cp' creates a nontrivial ACL for a directory when the original
    directory had none.
  - chmod 700 does not change the 'delete_child' bit for owner to "allow".

I propose to fix the first problem. The second problem is IMO a bug in the
kernel: /bin/chmod is affected as well.

Patch to come.

Bruno
-- 
In memoriam Erich Fellgiebel <http://en.wikipedia.org/wiki/Erich_Fellgiebel>