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