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 coreuti...@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 coreut...@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