Users, groups, and others

Under Linux, every file is owned by exactly one user and one group. Every user has an identifying number, the User ID (UID). The same applies for a group: it is resolved by a Group ID (GID). Every user has exactly one UID and one primary GID; however, users can be members of multiple groups. In that case, the user will have one or more supplementary GIDs. You can see this for yourself by running the id command on your Ubuntu machine:

reader@ubuntu:~$ id
uid=1000(reader) gid=1004(reader) groups=1004(reader),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd),1000(lpadmin),1001(sambashare),1002(debian-tor),1003(libvirtd)
reader@ubuntu:~$

In the preceding output, we can see the following things:

  • The uid for the reader user is 1000; Linux typically starts numbering normal users at 1000
  • The gid is 1004, which corresponds to the reader group; by default, Linux creates a group with the same name as the user (unless told specifically not to)
  • Other groups include adm, sudo, and others

What does this mean? The current logged-in user has a uid of 1000, a primary gid of 1004, and a few supplementary groups, which makes sure that it has other privileges. For example, under Ubuntu, the cdrom group allows the user to have access to the disk drive. The sudo group allows the user to perform administrative commands, and the adm group allows the user to read administrative files.

While we typically refer to users and groups by name, this is just a representation for the UIDs and GIDs that Linux provides us with. On a system level, only the UID and GIDs are important for permissions. This makes it possible, for example, to have two users with the same username but different UIDs: the permissions for those users will not be the same. The other way around is also possible: two different usernames with the same UID—this causes the permissions for both users to be the same, at least on the UID level. However, both situations are terribly confusing and should not be used! As we'll see later on, using groups to share permissions is by far the best solution for sharing files and directories.

Another thing to keep in mind is that UIDs and GIDs are local to the machine. So if I have a user named bob with UID 1000 on machine A, and UID 1000 is mapped to user alice on machine B, transferring bob's files from machine A to machine B would result in the files being owned by alice on system B!

The RWX permissions explained previously relate to the users and groups we're discussing now. In essence, every file (or directory, which is just a different type of file), has the following attributes:

  • The file is owned by a user, which has (part of) the RWX permissions
  • The file is also owned by a group, which again, has (part of) the RWX permissions
  • The file finally has RWX permissions for others, which means all different users that don't share the group

To determine if a user can read, write, or execute a file or directory, we need to look at the following attributes (not necessarily in this order):

  • Is the user the owner of the file? What RWX permissions does the owner have?
  • Is the user part of the group that owns the file? What RWX permissions have been set for the group?
  • Does the file have enough permissions on the others attribute?

Let's look at some simple examples before it gets too abstract. On your virtual machine, follow along with the following commands:

reader@ubuntu:~$ pwd
/home/reader
reader@ubuntu:~$ ls -l
total 4
-rw-rw-r-- 1 reader reader 69 Jul 14 13:18 nanofile.txt
reader@ubuntu:~$ touch testfile
reader@ubuntu:~$

First, we ensure that we are in the home directory for the reader user. If not, we can move back there by using the cd /home/reader command or, alternatively, by just entering cd (without an argument, cd defaults to the user's home directory!). We proceed by listing the contents of the directory in the long format, using ls -l, which shows us one file: nanofile.txt, from Chapter 2Setting Up Your Local Environment (don't worry if you didn't follow along there and do not have the file; we'll be creating and manipulating files in a little bit). We use a new command, touch, to create an empty file. The argument we specify for touch is interpreted as the file name, as we can see when we list the files again:

reader@ubuntu:~$ ls -l
total 4
-rw-rw-r-- 1 reader reader 69 Jul 14 13:18 nanofile.txt
-rw-rw-r-- 1 reader reader 0 Aug 4 13:44 testfile
reader@ubuntu:~$

You'll see the permission followed by two names: the username and the group name (in that order!). For our testfile, the user reader and members of the reader group can both read and write to the file, but cannot execute (on the position of the x, there is instead a -, indicating an absence of that permission). All other users, such as those that are neither readers nor part of the reader group (which, in this case, is really all other users), can only read the file due to the permission of others. This is also described in the following table:

File type
(1st character)

User permissions
(2nd to 4
th characters)

Group permissions
(5th to 7th characters)

Others permissions
(8th to 10th characters)

User ownership

Group ownership

- (normal file) rw-, read and write, no execute rw-, read and write, no execute r--, only read reader reader


If a file had full permissions for everyone, it would look like this: -rwxrwxrwx. For files that have all permissions for the owner and the group, but none for others, it would be -rwxrwx---. Directories with full permissions on user and group, but none for others, are represented as drwxrwx---.

 Let's look at another example:

reader@ubuntu:~$ ls -l /
<SNIPPED>
dr-xr-xr-x 98 root root 0 Aug 4 10:49 proc
drwx------ 3 root root 4096 Jul 1 09:40 root


drwxr-xr-x 25 root root 900 Aug 4 10:51 run
<SNIPPED>
reader@ubuntu:~$

The home directory for the systems' superuser is /root/. We can see from the first character on the line that it is a d, for directory. It has RWX (one last time: read, write, execute) permissions for the owner root, and no permissions for the group (also root), nor for others (as denoted by ---). These permissions can only mean one thing: only the user root can enter or manipulate this directory! Let's see if our assumption is correct. Remember, entering a directory requires the x permission, while listing the directory contents the r permission. We should not be able to do either, since we're neither the root user or in the root group. In this case, the permissions of others will be applied, this being ---:

reader@ubuntu:~$ cd /root/
-bash: cd: /root/: Permission denied
reader@ubuntu:~$ ls /root/
ls: cannot open directory '/root/': Permission denied
reader@ubuntu:~$
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.61.30