Working with a team

I’m working with a team that has not had a lot of experience working in Unix. We are in the process of setting up an Airflow server for some prototype or early production work. They all need to collaboriate in the same space for a bit. The are running into file permissions issues and I’ve suggested that the look into using ‘group’ permissions. Although, come to think of it, I’ve never really worked much with groups myself. Maybe I should give it a try myself before I start challenging them too much…

Use Cases

The team has provided some use cases and I have thought up a few myself. I believe the following use cases capture the essence of the need to collaborate in the same directory structure.

  • 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

Git?

You might be thinking: “Isn’t this what Git is for?” Enabling multiple developers to work on code together? Well yes. But at this point in development, the team is trying to integrate work into a single linux host for beta testing and load testing. I guess I would think of this as integration testing. The team needs to get a server up and running in place. Git defintely will help the team develop code together and share their work, however, when they need to integrate their work on a single server and run it 24x7, all people in the team will need the ability to adjust configurations and start/stop servers.

Challenges: No, you can’t have root

Barring root permission, I must ask a unix admin to perform specific commands. I would like to be able to provide them with all the necesary commands in one request.

Therefore I need a way to quickly setup a throw away Centos (Redhat) linux environment and own root so that I can quickly prototype the configuration.

Getting Started: docker

It seems like Docker is a pretty good fit here. I can pick my OS, pull an image, run in that image as root and walk through the use-cases as an administrator of my own little sandbox operating system.

Getting the image

I’m going to use a Centos image.

Pull the Centos docker container.

$ docker pull centos
Using default tag: latest
latest: Pulling from library/centos
a02a4930cb5d: Pull complete
Digest: sha256:184e5f35598e333bfa7de10d8fb1cebb5ee4df5bc0f970bf2b1e7c7345136426
Status: Downloaded newer image for centos:latest

Then run the image with interactive mode (-it) and delete the container after it closes (--rm).

$ docker run -it --rm centos

[root@2fe786d482b6 /]# export PS1='[\u \W]$ '

I also set the prompt environment variable to make the interaction easier to read.

Fortunately, the image has user management programs like useradd. So I proceed by adding a couple of fictional users users and run through the use cases that have come up with my development team.

Two protagonists & a villain

Let us create my two users Moss and Roy. To make things interesting, I’m going to also create a villain, Jen. Jen will help me explore some permission denied cases.

[root /]$ useradd moss
[root /]$ useradd roy
[root /]$ useradd jen

[root /]$ tail /etc/passwd -n 3
moss:x:1000:1000::/home/moss:/bin/bash
roy:x:1001:1001::/home/roy:/bin/bash
jen:x:1002:1002::/home/jen:/bin/bash

Moss and Roy will be working together on a very important project – Project Reynholm. They need to collaborate closely. In some cases, Moss may need to edit a file on disk that Roy has created and inversly, Roy may need to edit a file on disk that Moss has created. Jen will come in later.

Moss Starting out

Moss started work on the mysterious Project Reynholm alone. He asked the benevolent unix admin for some space to develop.

The unix admin gave them a drive mounted at /mnt/reynholm to work in. Since Moss was first on the scene, the unix admin give him ownership of the reynholm directory.

[root /]$ mkdir /mnt/reynholm
[root /]$ chown moss:moss /mnt/reynholm

[root /]$ ls -al /mnt
total 12
drwxr-xr-x  3 root root 4096 Dec 31 19:36 .
drwxr-xr-x 26 root root 4096 Dec 31 19:36 ..
drwxr-xr-x  2 moss moss 4096 Dec 31 19:36 reynholm

Moss then created the files he needed and proceeded to get work done.

[root /]$ su moss

[moss /]$ touch /mnt/reynholm/tinternet.txt

[moss /]$ ls -al /mnt/reynholm
total 8
drwxr-xr-x 2 moss moss 4096 Dec 31 19:38 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rw-rw-r-- 1 moss moss    0 Dec 31 19:38 tinternet.txt
[moss /]$ exit

Roy Arrives

Roy joined the team and he needed to work in the same directory as Moss. However when he ran into trouble immediately.

[root /]$ su roy

[roy /]$ touch /mnt/reynholm/tinternet.txt
touch: cannot touch '/mnt/reynholm/tinternet.txt': Permission denied

[roy /]$ echo 'TESTING' >> /mnt/reynholm/tinternet.txt
bash: /mnt/reynholm/tinternet.txt: Permission denied

[roy /]$ getfacl -pt /mnt/reynholm/tinternet.txt
# file: /mnt/reynholm/tinternet.txt
USER   moss      rw-     
GROUP  moss      rw-     
other            r--

Roy was unable to edit the tinternet.txt file because it is owned by Moss.

Roy was also unable to create another file in the /mnt/reynholm directory because it is also owned by Moss.

[roy /]$ touch /mnt/reynholm/tinternet.txt.new
touch: cannot touch '/mnt/reynholm/tinternet.txt.new': Permission denied

[roy /]$ exit
exit

Roy is pretty much unable to anything collaboratively in the /mnt/reynholm directory.

After a quick discussion between Roy and Moss, they came up with a great solution. They decided to open up the directory to all. This way they will both be able to work in the directory without permissions getting in the way at all!

[root /]$ su moss
[moss /]$ chmod -R ugo+rwx /mnt/reynholm
[moss /]$ ls -al /mnt/reynholm
total 8
drwxrwxrwx 2 moss moss 4096 Dec 31 19:38 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rwxrwxrwx 1 moss moss    0 Dec 31 19:38 tinternet.txt
[moss /]$ exit
exit

Problem solved!

Well, this is a big improvement. Roy was able to make edits and add new files to the /mnt/reynholm directory

[root /]$ su roy
[roy /]$ echo "TESTING" >> /mnt/reynholm/tinternet.txt
[roy /]$ touch /mnt/reynholm/tinternet.txt.new
[roy /]$ ls -al /mnt/reynholm
total 12
drwxrwxrwx 2 moss moss 4096 Dec 31 19:50 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rwxrwxrwx 1 moss moss    8 Dec 31 19:50 tinternet.txt
-rw-rw-r-- 1 roy  roy     0 Dec 31 19:50 tinternet.txt.new
[roy /]$ exit
exit

Enter Jen, Destroyer of work

Jen is just learning linux. She likes to keep things nice and neat. She is not working on Project Reynholm with Roy and Moss but she does have permission to login to the unix system. One day she decides to tidy things up in their messy /mnt/reynholm directory.

[root /]$ su jen

[jen /]$ ls -al /mnt/reynholm
total 12
drwxrwxrwx 2 moss moss 4096 Dec 31 19:50 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
-rwxrwxrwx 1 moss moss    8 Dec 31 19:50 tinternet.txt
-rw-rw-r-- 1 roy  roy     0 Dec 31 19:50 tinternet.txt.new

[jen /]$ rm -rf /mnt/reynholm
rm: cannot remove '/mnt/reynholm': Permission denied

[jen /]$ ls -al /mnt/reynholm
total 8
drwxrwxrwx 2 moss moss 4096 Dec 31 19:50 .
drwxr-xr-x 3 root root 4096 Dec 31 19:38 ..
[jen /]$ exit
exit

Well, now that’s much more tidy. Unfortunately for Moss and Roy all their hard work has been removed by Jen. Jen was able to do it because directory had o=rwx set. Leaving the directory open for others to write and execute allowed jen to delete the files. She could read the files because each file was readable by others. This would have been a secrecy issue, but in this case, Jen went with the nuclear option.

Moral of the story

To get this all working so that Moss and Roy can collaborate as well as prevent Jen from reading or deleting any of their work, they must use more sophisticated measures than simply granting full permissions to their work directory. They need groups and group access.

Setting up groups and group access will be the the topic of the my next post in this series: Using Groups for Collaborative Work

Mulitpart post

Because this work started to get too long for my attention span, I have broken it up into three parts:

References