24

A common way to set up a directory for file sharing within a group, is:

$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo

This ensures that any files created in foo is readable and writable by the group felles:

$ umask
0022
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar

However, if you copy a file into foo, the default ACLs are not applied:

$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
user::rw-
group::rwx          #effective:r--
group:felles:rwx        #effective:r--
mask::r--
other::r--

Why does this happen, and is there a way around it?

(Moving a file into the directory does not respect either ACLs or group ownership, but I can understand why: you might not want the permissions of a file to change simply because you change its name.)

1

6 Answers 6

12

If cp creates the destination file, it replicates the permissions of the source file, except for the bits that are set in the umask. This is standard behavior (see e.g. step 3.b in the Single Unix v3 (POSIX 2001) specification.

Why was cp designed this way? Because there are many cases where this behavior is desirable, for example preserving a file's privacy when the original permissions are restrictive, and preserving executability is almost always the right thing to do. It is however unfortunate that not even GNU cp has an option to turn this behavior off.

Most copy tools (e.g. pax, rsync) behave in the same way. You can ensure the file will be created with the default permission by decoupling the source from the destination, for example with cat <baz >foo/baz.

2
  • 1
    Well, that at least explains the motivation for it. (Strange, though, that the group ownership is allowed to change to "felles", giving potentially more people read access to the file.)
    – bhm
    Sep 23, 2010 at 22:07
  • I would like to point out that the problem is real. Can you help us solve it? unix.stackexchange.com/questions/711319 Jul 26, 2022 at 14:27
5

Well, a three-year old and more question but still relevant. For future readers, I want to add that it is expected that mv, cp commands do not follow destination directory's ACL. Gilles's answer is all fine but the last sentence. The better way to apply the destination's ACL to the copied/moved file is the way mentioned here:

http://www.commandlinefu.com/commands/view/4281/copy-acl-of-one-file-to-another-using-getfacl-and-setfacl

In case the link is broken in future, I paste the content here:

getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>

copy ACL of one file to another using getfacl and setfacl

WARNING: Existing ACL will get lost.

0
3

You need to use -p or --preserve with cp.

From man 5 acl:

CHANGES TO THE FILE UTILITIES

 On a system that supports ACLs, the file utilities ls(1), cp(1), and
 mv(1) change their behavior in the following way:

 ·   For files that have a default ACL or an access ACL that contains more
     than the three required ACL entries, the ls(1) utility in the long
     form produced by ls -l displays a plus sign (+) after the permission
     string.

 ·   If the -p flag is specified, the cp(1) utility also preserves ACLs.
     If this is not possible, a warning is produced.

 ·     The mv(1) utility always preserves ACLs. If this is not possible, a
     warning is produced.

 The effect of the chmod(1) utility, and of the chmod(2) system call, on
 the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND
 FILE PERMISSION BITS.
2
  • 7
    Not exactly. He wants the file to have the same permission as the target folder.
    – sdot257
    Sep 22, 2010 at 23:35
  • This answer should not have any thumbs up. The OP was not asking how to make the cp command preserve a files permissions. The OP was asking why ACLs are not applied to the copy of the file that the cp command made. Apr 1, 2023 at 17:03
2

I had a similar problem with rsynced files lacking the proper default ACLs in the target subdirectory. Cp does not have a way of setting the permissions on the target. But, rsync does, using the --chmod=ugo=rwx flag. See my answer here.

0

The ACLs are propagating correctly, but the default mask doesn't seem to be correct. You probably want your default mask to be rwX.

setfacl -dm m::rwX foo

If that doesn't work, please post the ACL for foo.

1
  • That did not work. The ACL for foo (both prior and after your command) is# file: foo # owner: bhm # group: felles # flags: -s- user::rwx group::rwx group:felles:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:felles:rwx default:mask::rwx default:other::r-x
    – bhm
    Sep 23, 2010 at 22:04
-1

From what I see you are the owner of the files (bhm) before and after the cp. As the directory listing shows the owner has read and write access!

1
  • Perhaps I was unclear: I want the group ("felles") to be able to (read and) write the file.
    – bhm
    Sep 23, 2010 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .