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?
Best Answer
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:
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 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 !!!!!!