Default ACL not inherited as Access ACL on copy and move

[Bib]

Ubuntu Desktop 14.04 fresh default installation
Default ACL and gid are set OK on parent folder (/srv/parent). (ext4)
mkdir child /srv/parent
and
touch /srv/parent/file /srv/parent/child/file
OK Both /srv/parent/file, /srv/parent/child/, /srv/parent/child/file show correct same acl as /srv/parent (getfacl)

cp -r /media/<user>/<label>/SomeTree ends in corrupted ACL where Access ACL mask::--- instead of rwx, resulting in acl set for named users and groups are ineffective. KO
Although, default:mask::rwx is ok.

For regular (i.e. non dir) files in the copied SomeTree, Access ACL mask::r-- instead of rwx, resulting in only r out of the set permissions for named users and groups will survive. KO

setfacl --set or -m reports no error

Workaround : grant permissions to users that would not have them, eg. o+rX or adduser reader writersgroup

[Bib (bybeu)]

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

[Bib (bybeu)]

More info: as umask is the ootb default (0002), it doesn't seem to be the thing that a default cp would ignore, because actually cp ignores it when an acl is involved. Instead, the culprit seems to be cp when cp ignores an acl when present and uses its usual mode bits when it would adopt the acl's ones in that situation. I still don't understand why many speak about mask or cp --preserve

[Bib (bybeu)]

http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg00002.html

[Seth Arnold (seth-arnold)]

Stay away from the patches provided in the linked email; I suspect the person who put it together does not regularly receive files named "foo ; rm -rf ~" from his friends.

[Bib (bybeu)]

Please Seth could you be more clear? I can't see the difference when an admin sets a default+access acl to some directory to grant write to a group, he knows what he does. Furthermore, imagine the admin is been under so heavy load so that he didn't got time enough to regrant the group write perm to newly copied data when such a mail comes with the attached file arrives... then what???? only the new data of group members others than the recipient would survive. Then what would you think of such an admin? He didn't backed up. Should he never use chmod g+sw at all ? And what prevents a user to destroy its own past contribution to a group team, killing the job of the whole team?
Sorry but not being native english, maybe I missed subtleties in your post.

[Seth Arnold (seth-arnold)]

Bib, I'm not saying that this bug is incorrect.

I'm saying that these patches are insecure and should not be used:

http://michael.orlitzky.com/code/releases/tar-1.27.1-gpcc.patch
http://michael.orlitzky.com/code/releases/coreutils-8.22-gpcc.patch

Do not use those patches. They are unsafe.

Thanks

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.