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

[Bernhard Voelker]

On 12/01/2014 09:51 AM, address@hidden 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