On 11/27/2014 11:28 AM, Bernhard Voelker wrote: > 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).
Thinking more about this, it seems to me that the ACL design is broken, as the ACL only takes effect iff the regular permission bits are sufficient, right? I mean, the ACLs have correctly automatically been inherited (without cp's help) ... and therefore, there's nothing we can do about it without either violating POSIX permission copying or adding several ACL-related calls although the user told us not to do so. Did I miss something? Have a nice day, Berny
