| tags: [ development linux shared work docker ] categories: [Development ]
Using Groups for Collaborative Work
In the first post: Collaborative Work Simple and Exposed, I walked through Moss and Roy’s current working configuration. I demonstrated the risk they face by Jen, the Destroyer of work, who could delete all their work or read files that should be protected.
In this post, I’ll walk through the steps needed to convert their working directory into a much safer setup using groups. This work will require some unix admin stesp and I will summarize those.
Here are the Use-cases that I introduced in the first post and I will referr to most of these throughout this post:
-
Share edit files: As a team of developers, we want to edit the same file (usually a configuration file).
-
Adding group perms: As a team of developers, we want to add new files and not have to always remember to change the group for each file.
-
Disallow intruders: As a team of developers, we do not want someone that is not part of the team to have write or delete permission to our working directory.
-
Modifying old files to add group: As a team of developers that have started out using ugo+rwx on all our files, we want to switch over to using a group and reduce our permissions down just the group (o-rwx)
-
Run a script as group: As a team of developers, we want anyone on the team to run a script and anyone else on the team is permitted to kill and restart the script
Setup
To start with, I have re-set the working directory /mnt/reynholm
at
the point where Moss was working alone and Roy was added into the
project.
[root /]$ su moss
[moss /]$ touch /mnt/reynholm/tinternet.txt
[moss /]$ ls -al /mnt/reynholm
total 8
drwxrwxrwx 2 moss moss 4096 Dec 31 19:56 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw-r-- 1 moss moss 0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit
Create a Group
When Roy started working on the project, they should ask the unix admin to create a group. Moss and Roy will need to bow their head to the Unix admin for several things.. this is the first.
[root /]$ groupadd stealth
[root /]$ tail -n 4 /etc/group
moss:x:1000:
roy:x:1001:
jen:x:1002:
stealth:x:1003:
Now we see that there is a group stealth
that has been created.
Another Unix admin request is needed to add both Roy and Moss
to the stealth
group.
[root /]$ usermod -a -G stealth moss
[root /]$ usermod -a -G stealth roy
[root /]$ id moss
uid=1000(moss) gid=1000(moss) groups=1000(moss),1003(stealth)
[root /]$ id roy
uid=1001(roy) gid=1001(roy) groups=1001(roy),1003(stealth)
Both Moss and Roy are now associated with the stealth group.
chgrp
the working directory
The directory /mnt/reynholm
was initially created by the Unix admin
and given to Moss. Now that there is a group available, Moss
or Roy will request that the Unix admin assign the stealth
group to
be the group owner of the /mnt/reynholm
directory.
[root /]$ ls -ald /mnt/reynholm
drwxrwxrwx 2 moss moss 4096 Dec 31 19:56 /mnt/reynholm
[root /]$ chgrp stealth /mnt/reynholm
[root /]$ ls -ald /mnt/reynholm
drwxrwxrwx 2 moss stealth 4096 Dec 31 19:56 /mnt/reynholm
With the stealth
group set as the group owner of the directory,
anyone within the group can read, write or execute in the
/mnt/reynholm
directory.
chmod
to restrict others
They will also ask the Unix admin to remove o=rwx permissions from the
directory.1
Changing ownership on the root of their working directory can be done by the owner of the directory – in this case that is Moss. Moss can issue the command:
[moss /]$ chmod o-rwx /mnt/reynholm
[moss /]$ ls -ald /mnt/reynholm
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 /mnt/reynholm
[moss /]$ getfacl -pt /mnt/reynholm
# file: /mnt/reynholm
USER moss rwx
GROUP stealth rwx
other ---
Removing other read, write and execute will remove the opportunity
from someone outside the group to read or modify anything within the
/mnt/reynholm
directory.
Each person check umask
Another precaution is for each member of the group to review their
umask setting. This setting is defined in the /etc/bashrc
but can
be re-set to within the $HOME/.bashrc
. He umask setting defines the
default permissions that will be applied to any new file that is
created by the user.
For example, Roy’s umask
setting is:
[root /]$ su roy
[roy /]$ umask
0002
[roy /]$ exit
exit
For Moss and Roy, the should completely lock out others from reading any newly created files, therefore thier individual umask should be set to 0007.
This can be done by adding the following line to the $HOME/.bashrc
umask 0007
For Moss and Roy, this is done by appending it to their
$HOME/.bashrc
su roy
echo "umask 007" >> $HOME/.bashrc
exit
su moss
echo "umask 007" >> $HOME/.bashrc
exit
After adding this to the .bashrc, the next time either of them logs in, the umask will be defined.
setgid
bit
Now both Roy and Moss can create files in the /mnt/reynholm
directory and they can edit existing files that they have
created. However they still can’t edit files that the other has
created.
For example, consider the case where both Moss and Roy create a file.
[root /]$ su roy
[roy /]$ touch /mnt/reynholm/royfile.txt
[roy /]$ exit
exit
[root /]$ su moss
[moss /]$ touch /mnt/reynholm/mossfile.txt
[moss /]$ exit
exit
[root /]$ ls -al /mnt/reynholm
total 8
drwxrwx--- 2 moss stealth 4096 Dec 31 20:59 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw---- 1 moss moss 0 Dec 31 20:59 mossfile.txt
-rw-rw---- 1 roy roy 0 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss 0 Dec 31 19:56 tinternet.txt
Moss cannot write to a file created by Roy:
[root /]$ su moss
[moss /]$ echo "TESTING FROM MOSS" >> /mnt/reynholm/royfile.txt
bash: /mnt/reynholm/royfile.txt: Permission denied
[moss /]$ exit
exit
And Roy cannot write to a file created by Moss:
[root /]$ su roy
[roy /]$ echo "TESTING FROM ROY" >> /mnt/reynholm/mossfile.txt
bash: /mnt/reynholm/mossfile.txt: Permission denied
[roy /]$ exit
exit
Both Moss and Roy could fix this up manually using chgrp
to change
the group owner over to the stealth
group.
[root /]$ su roy
[roy /]$ chgrp stealth /mnt/reynholm/royfile.txt
[roy /]$ ls -al /mnt/reynholm
total 8
drwxrwx--- 2 moss stealth 4096 Dec 31 20:59 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw---- 1 moss moss 0 Dec 31 20:59 mossfile.txt
-rw-rw---- 1 roy stealth 0 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss 0 Dec 31 19:56 tinternet.txt
[roy /]$ getfacl -pt /mnt/reynholm/royfile.txt
# file: /mnt/reynholm/royfile.txt
USER roy rw-
GROUP stealth rw-
other ---
[roy /]$ exit
exit
Once Roy has chowned the royfile.txt
to be group owned by stealth
,
then Moss is able to write information into the file.
[root /]$ su moss
[moss /]$ echo "TESTING FROM MOSS" >> /mnt/reynholm/royfile.txt
[moss /]$ exit
exit
This could be painful if they had to do it each time a new file was added to the directory. Both Moss and Roy could get around this by running a command to periodically change the permissions of any files:
find /mnt/reynholm/ -gid `id -g` -exec chgrp stealth {} \;
This find command will search all files and directories within the
/mnt/reynholm
directory where the group owner is the same
as the person running the command. For each file or directory that
meets this critera, find will execute the chgrp
command to change the
group ownership over to stealth
.
Fortunately there is another permissions change to fix this up in a more sustainable way and doesn’t require Moss and Roy to take proactive action.
The final Unix admin action needed is to set the setgid
bit on the
/mnt/reyholm
directory. This is done with the following command:
[root /]$ chmod g+s /mnt/reynholm
[root /]$ ls -ald /mnt/reynholm
drwxrws--- 2 moss stealth 4096 Dec 31 20:59 /mnt/reynholm
[root /]$ getfacl -p /mnt/reynholm
# file: /mnt/reynholm
# owner: moss
# group: stealth
# flags: -s-
user::rwx
group::rwx
other::---
After the setgid
bit is set on the directory, any files or
directories that are created within the /mnt/reynholm
directory will
automatically be created with the group owner of the containing
directory.
Here is an example with Moss driving:
[root /]$ su moss
[moss /]$ rm /mnt/reynholm/mossfile.txt
[moss /]$ touch /mnt/reynholm/mossfile.txt
[moss /]$ ls -al /mnt/reynholm/
total 12
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw---- 1 moss stealth 0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy stealth 18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss 0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit
In this example you can see that the /mnt/reynholm/mossfile.txt
file
has been re-created and it automatically receives the group owner of
the containing directory.
This is true with directories created as well:
[root /]$ su moss
[moss /]$ mkdir /mnt/reynholm/moss-subdir
[moss /]$ ls -al /mnt/reynholm
total 16
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 moss-subdir
-rw-rw---- 1 moss stealth 0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy stealth 18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss moss 0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit
Using the setgid
bit enables all members of the team to create
files within the group folder and share them, edit them, and delete
them because of the group permission.
Summary of admin steps
Because I spread the steps out a little, here is a summary of the unix admin steps needed to configure users and a directory for group work.
-
Create the group
groupadd stealth
-
Associate the users with the group
usermod -a -G stealth moss
-
Change the group owner on the directory
chgrp stealth /mnt/reynholm
-
Set the
setguid
bit on the directorychmod g+s /mnt/reynholm
And a reminder to the members of the group to review their umask
setting and restrict it as necessary in their $HOME/.bashrc
.
Cleaning up
Ok, so now that Moss and Roy have a group, are members of the group
and have the setguid
bit set on their shared working directory, they
still have a few files that are individually owned that should all be
set to have the stealth
group owner. This cleanup will have to be
executed by each that has non-group files or directories. Fortunately
the command made easier by the find
command.
[root /]$ su moss
[moss /]$ find /mnt/reynholm -gid `id -g` -ls
197 0 -rw-rw-r-- 1 moss moss 0 Dec 31 19:56 /mnt/reynholm/tinternet.txt
[moss /]$ find /mnt/reynholm/ -gid `id -g` -exec chgrp stealth {} \;
[moss /]$ ls -al /mnt/reynholm/
total 16
drwxrws--- 3 moss stealth 4096 Dec 31 21:02 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
drwxrws--- 2 moss stealth 4096 Dec 31 21:02 moss-subdir
-rw-rw---- 1 moss stealth 0 Dec 31 21:02 mossfile.txt
-rw-rw---- 1 roy stealth 18 Dec 31 20:59 royfile.txt
-rw-rw-r-- 1 moss stealth 0 Dec 31 19:56 tinternet.txt
[moss /]$ exit
exit
Jen the destroyer of work returns
Jen is back and she wants to tidy up again. What happens when she tries to clean up the /mnt/reynholm directory?
[root /]$ su jen
[jen /]$ ls /mnt/reynholm
ls: cannot open directory /mnt/reynholm: Permission denied
[jen /]$ rm -rf /mnt/reynholm/*
rm: cannot remove '/mnt/reynholm/*': Permission denied
[jen /]$ exit
exit
That’s right! She can’t! Since she is not included in the stealth
group and the directory world write and execute bits have been
removed, she is no longer able to clean up or even see what’s in the
/mnt/reynholm
directory.
Use Cases Followup
To refresh, here are the use-cases that I introduced at the beginning of the series.
- Share edit files
- I think this one has been demonstrated between Moss and Roy.
- Adding group perms
- Yep this one was just covered with
setguid
example.
- Yep this one was just covered with
- Disallow intruders
- We have shown that someone not in the group can be restricted
- Modifying old files to add group
- Covered that in the Cleanup section
- Run a script as a group
- Uh Oh!
- Well, I haven’t been able to demonstrate this one. Unfortunately this is more difficult than it looks. When I started this, I thought it was going to involve setgid bit, however it does not due to security risks. Controlling Shared Processes will be the subject of the last in this three part series:
Mulitpart post
Because this work started to get too long for my attention span, I have broken it up into three parts:
- Collaborative Work Simple and Exposed
- Using Groups for Collaborative Work
- Controlling Shared Processes
Reference
- https://unix.stackexchange.com/questions/134332/precedence-of-user-and-group-owner-in-file-permissions
groupadd
: https://www.unix.com/man-page/linux/8/groupadd/usermod
: https://www.unix.com/man-page/linux/8/usermod/umask
: https://www.linuxnix.com/umask-define-linuxunix/- https://askubuntu.com/questions/79565/how-to-add-existing-user-to-an-existing-group
- setgid details: https://en.wikipedia.org/wiki/Setuid#Effects_of_setuid_and_setgid
- setgid on scripts: https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts
-
Correction 2019/01/03. Realized that user that owns the directory can set permission bits on the directory. ↩︎