facl, setfacl, directory share, why does cp put the original file permissions into facl mask? Shouldn't that be cp -p behavior?

Question

The users on this system are careful and have their umasks set to the very private 0077. However, the users would like to have group specific directories, where files may be copied so as to explicitly share them just among other group members. There may be multiple such share directories though each is specific to a group.

Setting the group sticky bit on a given directory to be used for sharing is not enough. Although setting the sticky bit causes the group ownership to be correct on files placed in the directory, the permissions on said files are often set such that the files can not be read or edited, i.e. can not actually be shared. They just appear in the directory listing. This is because some users either don't think to, or don't know how to, manually make the required group permissions adjustment to allow read and write. We can give them a break on this because users are not admins, after all. acls can be used to specify that a particular group has access to the files in the share directory, independent of what the group permissions would have been without acls. That is the perfect solution, but it is not quite working.

In the following, the shared group is 'customer_gateway' and the example user trying to share a file is 'svw'. As can be seen in the transcript, the svw user is a member of the customer_gateway group. The directory where sharing is to occur is also called 'customer_gateway/'

The following uses acls. I set the group permissions, the default group permissions, the mask and the default mask. It works well for files created in the directory, or for files moved there via cat (or tar), but strangely, not for files that 'cp'ed there:

# rm -r customer_gateway/
# umask
0077
# cat ~/script1

mkdir customer_gateway
chown :customer_gateway customer_gateway/
chmod g+rwx  customer_gateway/
setfacl -m group:customer_gateway:rwX customer_gateway/
setfacl -m d:group:customer_gateway:rwX customer_gateway/
setfacl -m m::rwX customer_gateway/
setfacl -m d:m::rwX customer_gateway/
getfacl customer_gateway
cd customer_gateway
touch cga
cat << EOF > cgb
c g b
EOF
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway
user::rwx
group::rwx
group:customer_gateway:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:customer_gateway:rwx
default:mask::rwx
default:other::---

total 4
-rw-rw----+ 1 root root 0 Mar  2 20:43 cga
-rw-rw----+ 1 root root 6 Mar  2 20:43 cgb

# su - svw
/home/svw/bin:/usr/local/bin:/usr/bin:/bin

(note umask is 0077)

> cd /share/customer_gateway/
> groups
svw adm dip video plugdev google-sudoers customer_gateway
> cat >> cga
e f g
> cat > cgc
c g c
> ls -l
total 12
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
> ls ~/dat
ta  tb  tc
> cat ~/dat/ta > ta
> cp ~/dat/tb tb
> ls -l
total 20
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
-rw-rw----+ 1 svw svw 4 Mar  2 20:45 ta
-rw-------+ 1 svw svw 4 Mar  2 20:45 tb
> getfacl ta
# file: ta
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
mask::rw-
other::---
> getfacl tb
# file: tb
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---
mask::---
other::---
> 

What this shows is that when a file is created in the directory then it receives the default permissions and is sharable. But users don't always create their files there, commonly they cp them there.

But doing a copy is the same thing, because to do a copy we must first create a new file. We are talking about a plain copy here, not a preserve permissions copy. It is the same as the following form, which, btw does work and copies a file which will be sharable in the directory independent of its original group permissions:

cat < data.in  > shared/data.out

works just fine, piping through tar also works, but the form

cp data.in shared/data.out

fails. The cated file gets the default mask and default permissions. The cped file preserves its permissions in the acl mask and the group permissions, as though it was a cp -p (but it wasn't), and thus the effective permissions read like the original file, not the what the acls have been set to.

As a second try I ran this experiment with the group sticky bit, chmod g+rwxs, along with the facl changes, and got the exact same results. Although the directory listings are prettier due to the group ownership showing for all shared files. I also ran it with just the group sticky bit being set, without the setfacl. It also had the same result for copied files (so facls look fairly useless for a directory where files are copied in to be shared).

On what basis and with what justification does linux facls distinguish between different forms of creating data? Why force cp to preserve permissions when it hasn't been told to do this? What reason would justify the confusion caused by this distinction between cat and piping through tar working but cp not working? Am I missing a magic incantation that would make this distinction evaporate?

Is this summary correct: facls will allow you to overcome ownership to share files, it will make permissions more permissive than the umask when 'creating' files, unless that creation is due to the cp command and for good reason because ... because why?

Answer 1

All answers so far have given advice on how to deal with sharing file via group directories. Non has answered you main question, I think, which was: Why does cp a b behave as if cp -p a b was specified? The man page does not talk about it, indeed, but texinfo has the details. info coreutils 'cp invocation' shows:

 ‘-p’
 ‘--preserve[=ATTRIBUTE_LIST]’
 Preserve the specified attributes of the original files. ...
 
 ...

 In the absence of this option, the permissions of existing
 destination files are unchanged.  Each new file is created with the   <===
 mode of the corresponding source file minus the set-user-ID,          <===
 set-group-ID, and sticky bits as the create mode; the operating
 system then applies either the umask or a default ACL, possibly
 resulting in a more restrictive file mode.
 
 ...

So, if the destination exists, the content is replaced, but the mode bits are not changed. If the destination does not exist, mode bits are copied from source.

Answer 2

This fact of making a directory where users can go into is pretty simple and can easily be done.

• Firstly you will need to find an appropriate place to make this directory, I reccomend making it under a directory which is accessible to all (for the moment). Use the command sudo mkdir to create your new directory.

• Secondly you need to make a group, a group is simply a collection of users which are rounded up in order to restrict or access certain parts of a linux system. You may have seen groups when typing the ls -l command which lists something like this:

rwxrwxrwx 3 root admins 4736 Oct 24 12:32 File1.doc

The part that says root is the owner and **admins ** is the group which owns the file. Groups ensure an easy way to allow certain people to view files. To make a group type the "sudo groupadd , this will be the group used for the directory.

• Once the groups been made you can add users to it which you want to access the directory, by using the following command sudo adduser This will allow you to add users you can verify if the user is in the group with the group command.

Once this is done browse to the directory you created and set the group permission to 7 (rwx) remember you can adjust these to your preferences but 7 gives users of the group full permissions to the directory, you can do this by typing "sudo chmod 770"

Next you need to change the group ownership of the directory, so the group owner of the directory is the group you made, do this with with the following command "sudo chown -R :groupname .

Once this has all been done you can now add whomever you wish to the group and they will have access to copy and share files as long as they are in that specific group to access the directory. Please let me know if you found this helpful !!!!!!

Answer 3

I would remove all acl's and just use user and group permissions. Then chmod 777 the folder you want everyone to have access to. Then test your access.

Then chmod 770 the folder test access again.

When this work as it should then add acl's back in one at a time.

If they do not need execute perms you could reduce it even lower to rw*,rx*,*** with chmod 660 foldername

Remember for the period where you have no acl's and chmod 777 permissions your folder will be wide open to all so don't leave it like that.

Answer 4

I tried it. It seems that the umask is clobering the group permissions, as the group permissions are the mask of the ACL. It is blocking all groups and ACLs.

A work around is to make the umask less restrictive. To do this safely you need to add a group for each user, and make this group the default group. (see Why does every user have their own group? ).

This is not ideal, as there is still a case for different umasks (g=rx, and g=rwx). This strategy only removes the need for no group permissions.