As we've stated before, Linux is inherently a multi-user system, especially in the context of a Linux server, where these systems are often administered not by a single user, but often a (large) team. Each user on a server has it own set of permissions. Imagine, for example, a server where three departments need to be development, operations, and security. Development and operations both have their own stuff there, but also need to share some other things. The security department needs to be able to view everything to ensure proper compliance and adherence to security guidelines. How could we arrange such a structure? Let's make it happen!

First, we need to create some users. For each department, we will create a single user, but since we're going to ensure permissions on the group level, this will work just as well for 5, 10, or 100 users in each department. We can create users with the useradd command. In its basic form, we can just use useradd <username>, and Linux will handle the rest via default values. Obviously, as with almost everything in Linux, this is highly customizable; check the man page (man useradd) for more information.

As was the case with chown and chgrp, useradd (and later usermod) is a privileged command, which we will execute with sudo:

reader@ubuntu:~$ useradd dev-user1
useradd: Permission denied.
useradd: cannot lock /etc/passwd; try again later.
reader@ubuntu:~$ sudo useradd dev-user1
[sudo] password for reader: 
reader@ubuntu:~$ sudo useradd ops-user1
reader@ubuntu:~$ sudo useradd sec-user1
reader@ubuntu:~$ id dev-user1
uid=1001(dev-user1) gid=1005(dev-user1) groups=1005(dev-user1)
reader@ubuntu:~$ id ops-user1 
uid=1002(ops-user1) gid=1006(ops-user1) groups=1006(ops-user1)
reader@ubuntu:~$ id sec-user1 
uid=1003(sec-user1) gid=1007(sec-user1) groups=1007(sec-user1)
reader@ubuntu:~$

As a last reminder, we've showed you what happens when you forget sudo. While the error message is technically fully correct (you need root permissions to edit /etc/passwd, where user information is stored), it might not be fully obvious why the command is failing, especially because of the misleading try again later! error.

With sudo, however, we are able to add three users: dev-user1, ops-user1, and sec-user1. When we inspect these users in order, we can see that their uid goes up by one each time. We can also see that a group with the same name as the user is created, and that that is the sole group of which the users are a member. Groups also have their gid, which is incremented by one for each next user.

So, now we have the users in place, but we need shared groups. For this, we have a similar command (both in name and operation): groupadd. Check the man page for groupadd and add three groups corresponding to our departments:

reader@ubuntu:~$ sudo groupadd development
reader@ubuntu:~$ sudo groupadd operations
reader@ubuntu:~$ sudo groupadd security
reader@ubuntu:~$

To see which groups are already available, you can check out the /etc/group file (with, for example, less or cat). Once you're satisfied, we now have the users and groups in place. But how do we make the users members of the groups? Enter usermod (which stands for user modify). The syntax to set a user's primary group is as follows: usermod -g <groupname> <username>:

reader@ubuntu:~$ sudo usermod -g development dev-user1 
reader@ubuntu:~$ sudo usermod -g operations ops-user1 
reader@ubuntu:~$ sudo usermod -g security sec-user1 
reader@ubuntu:~$ id dev-user1 
uid=1001(dev-user1) gid=1008(development) groups=1008(development)
reader@ubuntu:~$ id ops-user1 
uid=1002(ops-user1) gid=1009(operations) groups=1009(operations)
reader@ubuntu:~$ id sec-user1 
uid=1003(sec-user1) gid=1010(security) groups=1010(security)
reader@ubuntu:~$

What we have accomplished now is closer to our goal, but we're not there yet. So far, we have only ensured that multiple developers can share files by all being in the development group. But how about the shared folder between development and operations? And how can security monitor everything? Let's create some directories (using mkdir, which stands for make directory) with the correct groups and see how far we can get:

reader@ubuntu:~$ sudo mkdir /data
[sudo] password for reader:
reader@ubuntu:~$ cd /data
reader@ubuntu:/data$ sudo mkdir dev-files
reader@ubuntu:/data$ sudo mkdir ops-files
reader@ubuntu:/data$ sudo mkdir devops-files
reader@ubuntu:/data$ ls -l
total 12
drwxr-xr-x 2 root root 4096 Aug 11 10:03 dev-files
drwxr-xr-x 2 root root 4096 Aug 11 10:04 devops-files
drwxr-xr-x 2 root root 4096 Aug 11 10:04 ops-files
reader@ubuntu:/data$ sudo chgrp development dev-files/
reader@ubuntu:/data$ sudo chgrp operations ops-files/
reader@ubuntu:/data$ sudo chmod 0770 dev-files/
reader@ubuntu:/data$ sudo chmod 0770 ops-files/
reader@ubuntu:/data$ ls -l
total 12
drwxrwx--- 2 root development 4096 Aug 11 10:03 dev-files
drwxr-xr-x 2 root root        4096 Aug 11 10:04 devops-files
drwxrwx--- 2 root operations  4096 Aug 11 10:04 ops-files
reader@ubuntu:/data

We now have the following structure: a /data/ top level directory, which contains the directories dev-files and ops-files, which are owned by the development and operations groups, respectively. Now, let's fulfill the requirement that security can go into both directories and manage the files! Apart from using usermod to change the main groups, we can also append users to extra groups. In this case, the syntax is usermod -a -G <groupnames> <username>. Let's add sec-user1 to the development and operations groups:

reader@ubuntu:/data$ id sec-user1
uid=1003(sec-user1) gid=1010(security) groups=1010(security)
reader@ubuntu:/data$ sudo usermod -a -G development,operations sec-user1 
reader@ubuntu:/data$ id sec-user1
uid=1003(sec-user1) gid=1010(security) groups=1010(security),1008(development),1009(operations)
reader@ubuntu:/data$

The user from the security department is now a member of all new groups: security, development, and operations. Since both /data/dev-files/ and /data/ops-files/ do not have permissions for others, our current user should not be able to enter either, but sec-user1 should be. Let's see if this is correct:

reader@ubuntu:/data$ sudo su - sec-user1
No directory, logging in with HOME=/
$ cd /data/
$ ls -l
total 12
drwxrwx--- 2 root development 4096 Aug 11 10:03 dev-files
drwxr-xr-x 2 root root        4096 Aug 11 10:04 devops-files
drwxrwx--- 2 root operations  4096 Aug 11 10:04 ops-files
$ cd dev-files
$ pwd
/data/dev-files
$ touch security-file
$ ls -l
total 0
-rw-r--r-- 1 sec-user1 security 0 Aug 11 10:16 security-file
$ exit
reader@ubuntu:/data$

If you followed along with this example, you should see that we introduced a new command: su. Short for switch user, it allows us to, well, switch between users. If you prefix it with sudo, you can switch to a user without needing the password for that user, as long as you have those privileges. Otherwise, you will have to enter the password (which is hard in this case, since we haven't set a password for the user). As you might have noticed, the shell is different for the new user. That's because we haven't loaded any configuration (which is automatically done for the default user). Don't worry about that, though—it's still a fully functioning shell! Our test succeeded: we were able to move into the dev-files directory, even though we are not a developer. We were even able to create a file. If you want, verify that the same is possible for the ops-files directory.

Finally, let's create a new group, devops, which we will use to share files between developers and operations. After creating the group, we will add both dev-user1 and ops-user1 to this group, in the same way we added sec-user1 to the development and operations groups:

reader@ubuntu:/data$ sudo groupadd devops
reader@ubuntu:/data$ sudo usermod -a -G devops dev-user1 
reader@ubuntu:/data$ sudo usermod -a -G devops ops-user1 
reader@ubuntu:/data$ id dev-user1 
uid=1001(dev-user1) gid=1008(development) groups=1008(development),1011(devops)
reader@ubuntu:/data$ id ops-user1 
uid=1002(ops-user1) gid=1009(operations) groups=1009(operations),1011(devops)
reader@ubuntu:/data$ ls -l
total 12
drwxrwx--- 2 root development 4096 Aug 11 10:16 dev-files
drwxr-xr-x 2 root root        4096 Aug 11 10:04 devops-files
drwxrwx--- 2 root operations  4096 Aug 11 10:04 ops-files
reader@ubuntu:/data$ sudo chown root:devops devops-files/
reader@ubuntu:/data$ sudo chmod 0770 devops-files/
reader@ubuntu:/data$ ls -l
total 12
drwxrwx---  2 root development 4096 Aug 11 10:16 dev-files/
drwxrwx---  2 root devops      4096 Aug 11 10:04 devops-files/
drwxrwx---  2 root operations  4096 Aug 11 10:04 ops-files/
reader@ubuntu:/data$

We now have a shared directory, /data/devops-files/, where both dev-user1 and ops-user1 can enter and create files.

As an exercise, do any of the following:

• Add sec-user1 to the devops group, so that it can also audit the shared files
• Verify that both dev-user1 and ops-user1 can write files in the shared directories
• Understand why dev-user1 and ops-user1 can only read each other's files in the devops directory, but cannot edit them (hint: the next section of this chapter, Advanced permissions, will tell you how to solve this with SGID)