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

[Bob Proulx]

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 address@hidden
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 address@hidden 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