#StackBounty: #permissions #acl #file-sharing #setfacl facl, setfacl, directory share, why does cp put the original file permissions in…

Bounty: 50

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
# 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
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway

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

(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
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
> getfacl tb
# file: tb
# owner: svw
# group: svw
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---

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?

Get this bounty!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.