bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.

[Bernhard Voelker]

[sorry for the double-post to you guys, I wasn't aware that the
bug was already archived.]

On 10/20/2014 12:57 AM, Bob Proulx wrote:
> f0rhum wrote:
> > cool working mkdir and touch? These two were made compliant with default
> > extended acls, so why not cp and mv?
>
> I don't know.  Why not?  You tell me.  What is the problem?  You
> haven't said what the problem is.  What are you seeing?  Can you
> provide a small test case that illustrates whatever problem you are
> talking about?

I guess he's talking about the following test case (available on
Michael Orlitzky's page [0]).

[0] 
http://michael.orlitzky.com/articles/fixing_posix_acls_in_common_utilities.php

   $ mkdir acl
   $ cd acl

   $ # set the default ACL so that user 'lilly' has full rights.
   $ setfacl -d -m user:lilly:rwx .

   $ cp /etc/profile ./
   $ getfacl profile
   # file: profile
   # owner: berny
   # group: users
   user::rw-
   user:lilly:rwx                    #effective:r--
   group::rwx                      #effective:r--
   mask::r--
   other::r--

   $ ls -ldog profile
   -rw-r--r--+ 1 10019 Nov 27 11:14 profile

Since the file has inherited the permissions from the original
file, the default ACLs set on the directory don't have any effect
on the file, i.e., user lilly can not write the file.

Interestingly, that's different with touch(1).

If I understand it right, then this makes the default ACLs useless
for the case it would widen the access on the files; the ACLs have
to be fixed afterward manually.

On the downstream SUSE bugtracker, we've received the same
complaint in the meantime (bug#902060, not open to the public).

Have a nice day,
Berny