GNU bug report logs - #18748
cp doesn't behaves as mkdir and touch when a default acl exists.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18748 in the body.
You can then email your comments to 18748 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: f0rhum <f0rhum <at> free.fr>
To: bug-coreutils <at> gnu.org
Subject: cp doesn't behaves as mkdir and touch when a default acl exists.
Date: Thu, 16 Oct 2014 21:15:21 +0200

Hi gnu world
I posted a monologue about this in the list
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.
Another got more audience:
http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg00001.html
Well I read the coreutils FAQ and other the rtfm link, and I think it's
time to ask if we could have a question for this in the coreutils FAQ,
with the same brillant style than the ones for
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
and
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-don_0027t-the-utilities-have-built-in-directory-recursion_003f
, both refering to Unix philosophy, and both great light for
half-gnubies like me.
This one could be called "Why don't we have automatic inheritance of
permissions with default extented acl?"
This is a too long title, but too short to paint the landscape.
I know acl definition in the POSIX 1e draft 17 is a withdraw job.
I know acl is neither in coreutils nor even in GNU. I also now that the
N in GNU stands for "not", so why "not" adopt the job further like yet
cool working mkdir and touch? These two were made compliant with default
extended acls, so why not cp and mv?
I also know sgid is a step on the path of inheritance, but not enough
when another group is needed.
I think (maybe I think bad) that cp and mv, at least on local, when run
__without-any-option-directly-related-to-the-permissions-mode-bits__ and
then meet a default acl set at the destination directory, would discard
they traditionnal behavior (that is re-writing permissions according to
umasked process and/or mount ones, not sure) and instead would rewrite
according only the said default acl as long as the process already has
the write permission. Gureeks are there to mitigate my imagination ;-)
Michael Orlitzky (aka copyright sucks) already did such a job, so why
not make room for him? (or maybe it's already a WIP?)
At least the FAQ would explain why 2 groups is one too much, both in
Unix and GNU philosophies.

Thank you

Fabrice

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

From: Bob Proulx <bob <at> proulx.com>
To: f0rhum <f0rhum <at> free.fr>
Cc: 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Sun, 19 Oct 2014 16:57:17 -0600

Hello Fabrice,

f0rhum wrote:
> Hi gnu world
> I posted a monologue about this in the list
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.
> Another got more audience:
> http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg00001.html
> Well I read the coreutils FAQ and other the rtfm link, and I think it's
> time to ask if we could have a question for this in the coreutils FAQ,
> with the same brillant style than the ones for
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
> and
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-don_0027t-the-utilities-have-built-in-directory-recursion_003f
> , both refering to Unix philosophy, and both great light for
> half-gnubies like me.

I am glad you enjoyed those entries.  That is why they were written.
It is good to hear that people are appreciative of them.

> This one could be called "Why don't we have automatic inheritance of
> permissions with default extented acl?"

One of the problems I personally would have in writing an ACL entry is
that I personally don't use ACLs and therefore do not know them well
enough to write a good FAQ entry that covers ACLs.  I don't have the
experience with them.  If you (or anyone else) is using ACLs and knows
them well then would you consider writing up an FAQ entry and
submitting it?  The best time to documentation is when you are
learning something because that is when you still remember what you
needed to know about it.

> This is a too long title, but too short to paint the landscape.
> I know acl definition in the POSIX 1e draft 17 is a withdraw job.
> I know acl is neither in coreutils nor even in GNU. I also now that the
> N in GNU stands for "not", so why "not" adopt the job further like yet

If it wasn't obvious the Not in GNU had to do with the closed source
proprietary license of Unix.  And GNU was not closed.  And there were
many other improvements too.  Along with some bad things too.  Nothing
is perfect.

> 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?

Are you talking about Bug#8527[1].  If so did you intend to open a new
bug report here?  Perhaps you intended to add a comment to that bug
ticket?  If so then it would have been better simply to mail that bug
ticket instead of creating a new one.  If so we will merge this ticket
with that one and continue the discussion there.

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.

If you just want general discussion please use coreutiles <at> gnu.org
instead.  That is for general discussion.  It is a normal mailing
list.  It is not a bug list and does not open a bug ticket each time.
I think that might be where you intended to send this message.

> I also know sgid is a step on the path of inheritance, but not enough
> when another group is needed.
> I think (maybe I think bad) that cp and mv, at least on local, when run
> __without-any-option-directly-related-to-the-permissions-mode-bits__ and
> then meet a default acl set at the destination directory, would discard
> they traditionnal behavior (that is re-writing permissions according to
> umasked process and/or mount ones, not sure) and instead would rewrite
> according only the said default acl as long as the process already has

Upon reading this I think you are looking for discussion.  That is
great.  Discussion is best handled on the coreutils <at> gnu.org mailing
list.  Therefore I am going to close this as a bug ticket just to keep
the accounting clear.  If this thread continues and there is a bug
logged here then it can trivially be opened again to track the status
of it into the next release.

> the write permission. Gureeks are there to mitigate my imagination ;-)
> Michael Orlitzky (aka copyright sucks) already did such a job, so why
> not make room for him? (or maybe it's already a WIP?)
> At least the FAQ would explain why 2 groups is one too much, both in
> Unix and GNU philosophies.

I am sorry but you have completely lost me there.

Bob

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

From: f0rhum <at> free.fr
To: Bob Proulx <bob <at> proulx.com>
Cc: 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Mon, 20 Oct 2014 18:21:11 +0200 (CEST)

Hi Bob,
Thank you for this detailed answer

>> I posted ...in
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527...
>> http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg00001.html
>> .. I ask ...if we could have a question for this in the coreutils FAQ...
>> 
> One of the problems I personally would have in writing an ACL entry is
> that I personally don't use ACLs and therefore do not know them well
> enough to write a good FAQ entry that covers ACLs.  I don't have the
> experience with them.  If you (or anyone else) is using ACLs and knows
> them well then would you consider writing up an FAQ entry and
> submitting it?  The best time to documentation is when you are
> learning something because that is when you still remember what you
> needed to know about it.

Well Bob, I'm too newby in GNU/Linux to dare writing any documentation.
Although, and yet a lot of tips-'n-tricks on acl exists on the web,
they all lack the GNU philosophy background we find in the coreutils FAQ. 
And the sad thing is that Internet is the place where I find so much people
ready to help, but who are not sure... because they do not use.  Not using
alc yourself, I really appreciate you do not try to answer.  I must confess
I can't always curb myself.

>> 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?

> Are you talking about Bug#8527[1].  If so did you intend to open a new
> bug report here?  Perhaps you intended to add a comment to that bug
> ticket?  If so then it would have been better simply to mail that bug
> ticket instead of creating a new one. If so we will merge this ticket
> with that one and continue the discussion there.
> [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.

Yes Bob, I posted a case there (*).  And I got feedback, and even a workaround.
Unfortunately, newb I am, and I went yet again stuck, namely at
install time (I walked the compilation step, but newb I am and I can't say
if the log states anything wrong).
Furthermore, cp being a core utility, I'm afraid I break my system if I do something
wrong leaving it without a cp feature probably pre-required to reinstall the genuine one.
Furfurthermomore, when I posted this workaround in the bug tracker to which
I first submitted the ~bug~, a guy discouraged me using it (spartan "dangerous")
because of a "foo ; rm -rf tilde" thing that might fall from the skies.  With no
reply to him from a gureex, I dared my own newb's reply which remained
huheeded ( https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1376443 ).
And then I'm pretty sure you know/remember that "make" is a swearword for
an average user, surely ruder than acl is if we consider the underlying complexity
of each other, isn't it?
(* I realize this is not of good practice to appends one's issue to
another existing one.  Again, I didn't want to flood with my big shoes and 
(wrongly?) thought it would be more constructive if ~related~ issues were
together.)

So, as I didn't want to flood the bug list here, and still being stuck
after I re-re-read and re-re-re-read all I could find (man, info, drafts...)
and went back to the coreutils faq (hoping I missed something of huge obviousness),
where I found this (after I searched again for acl and permissions):

"...If you still don’t find a suitable answer,
consider posting the question to the bug list." 
Well, I didn't want to flood, I'm advised too :/ ... so I did.
Not really sure I hit a bug or my own nullity, I think asking
a faq item in coreutils was then the best place for others in my breed
... unless I am a breed all on my own :), but I don't think so.

If I went on posting here <at>gnu, it is because I feel my issue is of that kind
we call "patate chaude" in french: ubuntu, debian, gnu, savannah,
acl-devel<at>gnu|nongnu.org... who wants the hot potatoe? ;) ... nobody?? OMR, did I
find another French Administration? :(      (Oh My Robespierre).


> If you just want general discussion please use coreutiles <at> gnu.org
> instead.  That is for general discussion.  It is a normal mailing
> list.  It is not a bug list and does not open a bug ticket each time.
> I think that might be where you intended to send this message.

Not really what I wanted... see above.  But as you advise, I'll do.


>> the write permission. Gureeks are there to mitigate my imagination ;-)
>> Michael Orlitzky (aka copyright sucks) already did such a job, so why
>> not make room for him? (or maybe it's already a WIP?)
>> At least the FAQ would explain why 2 groups is one too much, both in
>> Unix and GNU philosophies.

> I am sorry but you have completely lost me there.

Sorry Bob, I know I often get the verbal diarrhea disease (call it
logorrhea if you want, I can't see a kind difference).  When I feel so
tired in searching, I'd rather like to be more precise, fearing the
single really skilled person in the world reading the post would
drop it as poorly decorated with juicy details.  Here how it plays: 
I ask a simple question, helper requires more details, I give...
then silence or equivalent... so I post details elsewhere until I find ... or not.

I only wanted to say this, that if we can't imagine that 2 groups (**)
with different permissions may need access to a same file|dir|tree, then
we don't need acl... at all.
This was a reference to my case in the bug #8527.
(** none of them being neither the object owner private group nor "others")

Bye bye

Maybe I'll read you in the discussion list? Let me know.

Fabrice

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Bob Proulx <bob <at> proulx.com>, f0rhum <f0rhum <at> free.fr>
Cc: 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Thu, 27 Nov 2014 11:28:20 +0100

[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

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Bob Proulx <bob <at> proulx.com>, f0rhum <f0rhum <at> free.fr>
Cc: 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Sat, 29 Nov 2014 17:18:30 +0100

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

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

From: f0rhum <at> free.fr
To: 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Mon, 1 Dec 2014 09:51:16 +0100 (CET)

> 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?

"...although the user told us not to do so..."

Hi Bernie
I'm still puzzled 
So do you mean the only way not to violate POSIX permissions is to respect "what the user tells to do"?
Then let's get a look at what the user tells:
First, use POSIX (basic) permissions
THEN, add ACL support (to be read below "extended ACL support")

Reverting the sequence is pure non sense (but if I first choose a system with native ACL support like NT), so if the 2nd step is a violation of the 1st one, then the 2nd one (violating) would just made be impossible so that said ACL support concept doesn't even exist.

ACL support being currently advertised, I feel I legitimately want to see it applied as superseding the basic permissions set where (such or such tree) ***me-the-user*** want this superset to apply.

If I'm wrong, at least ACL would be renamed to ACR (Access Control Restrictions) according to the current behaviour with cp/mv.

Fabrice-the-user

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: f0rhum <at> free.fr, 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists.
Date: Thu, 11 Dec 2014 09:57:30 +0100

On 12/01/2014 09:51 AM, f0rhum <at> free.fr wrote:
>> 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?
>
> "...although the user told us not to do so..."
>
> Hi Bernie
> I'm still puzzled
> So do you mean the only way not to violate POSIX permissions is to respect "what the user tells to do"?

The point is that this is not only a problem of cp(1),
but affects all programs which only open(..., 0644), e.g.

---------------8<---------------
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
  int fd = open("./testfile", O_WRONLY|O_CREAT|O_EXCL, 0644);
  if (-1 <= fd)
    return 1;
  return 0;
}
--------------->8---------------
Simply compile with "gcc -Wall -o prg prg.c", and run in that
default-ACLed directory ("setfacl -d -m user:lilly:rwx .").
The resulting "testfile" will also not be writeable by that other
user.

The crucial point with the cp(1) example is that the source file
is not group-writeable; therefore, the target file isn't either.

If the source were already group-writable, then the target would
be, too, and the ACL could take effect. Just check with a different
file:

  $ touch /tmp/otherfile \
      && chmod g+r /tmp/otherfile \
      && cp /tmp/otherfile .

Thinking more about this, my guess is that this can be seen as a security
feature of default ACLs: if a file is copied from another place and group
members did not have write permissions there, then this still applies to
the copy in the default-ACLed directory.

The only way out is really fixing the ACLs - which looks too expensive
for cp(1) to me.

Maybe a new "--apply-default-acls-from-target-dir" option?
Any other ideas or conclusions?

Have a nice day,
Berny

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

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: 18748 <at> debbugs.gnu.org
Subject: Re: cp doesn't behaves as mkdir and touch when a default acl exists
Date: Mon, 13 Apr 2015 01:10:21 +0200

When a file is copied with cp, the default is to create the new file
in the target directory, with the file mode of the original file as
the create mode. This default can be overridden with cp's -p or
--preserve=mode options.

This has the following effect:

 * In the absence of a default acl, the new file will have the original
   file's permission bits minus the umask.

 * In the presence of a default acl, the default acl replaces the umask.
   The new file will inherit the default acl, which results in an imaginary
   file mode. The actual file mode is set to the intersection of the original
   file's permission bits and this imaginary file mode.

This is not a bug, it is the expected and documented behavior; see the
POSIX standard, POSIX 1003.1e/2c draft standard [*], and also the
coreutils info pages (info coreutils 'cp invocation') which could be
improved.

[*] http://wt.tuxomania.net/publications/posix.1e/download.html

Andreas

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Andreas Grünbacher
 <andreas.gruenbacher <at> gmail.com>, 18748 <at> debbugs.gnu.org
Subject: Re: bug#18748: cp doesn't behaves as mkdir and touch when a default
 acl exists
Date: Mon, 13 Apr 2015 09:42:18 +0100

On 13/04/15 00:10, Andreas Grünbacher wrote:
> When a file is copied with cp, the default is to create the new file
> in the target directory, with the file mode of the original file as
> the create mode. This default can be overridden with cp's -p or
> --preserve=mode options.
> 
> This has the following effect:
> 
>  * In the absence of a default acl, the new file will have the original
>    file's permission bits minus the umask.
> 
>  * In the presence of a default acl, the default acl replaces the umask.
>    The new file will inherit the default acl, which results in an imaginary
>    file mode. The actual file mode is set to the intersection of the original
>    file's permission bits and this imaginary file mode.
> 
> This is not a bug, it is the expected and documented behavior; see the
> POSIX standard, POSIX 1003.1e/2c draft standard [*], and also the
> coreutils info pages (info coreutils 'cp invocation') which could be
> improved.

Your improvement pull request is now pushed at
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=88e4910

thanks!
Pádraig.

Previous Next

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