In this section, we'll introduce the concepts of user and group management. When working in computer systems, it's really common to utilize user and group management. In Linux, it's no different. User accounts in Linux are used to provide unique credentials and provide security boundaries between the various users on the system. Each user will have a unique username as well as a user ID number, that the operating system manages. This will then be coupled with access to various parts of the operating system itself and managed throughout complex permissions that are available. Each user ID or UID must be unique throughout the system. This will correspond to the various access that they have throughout files and folders. We have three main types of users when it comes to Linux, we have a superuser, a system user, and regular user. The purpose of the superuser account is for administrative purposes. By default, the superuser account is known as root. The root user is stored in the UID 0. This user or superuser has full access to the entire system. The next type of user is a system user. System users are responsible for running the processes throughout the operating system. You could think of these as managed by the kernel or the operating system itself because they're used to launch the various processes that make our experiences happen. The processes or daemons that run consistently throughout the operating system, don't need to run with all of the administrative privileges that the superuser has, and instead are run as system users with the proper delegated authorities that the particular application or process require. Our most common type of user is just a regular user. This is one that you would use in your day-to-day work and would be coupled with a username and password so that you can access the files and systems you need within your Linux operating system. When you need to view information about a specific user that you're logged in with, you can use the id command. Here you can see a sample output of the id command when logged in as a sample user, in this case, user01. We can see that the UID information is given. In this case, with the UID 1000, coupled with that username. There's a group ID generated as well. Here the GID is 1000 that corresponds with a group named, user01 as well. When we create regular users, a corresponding group of the same name as also created. Lastly, we can see any groups that they may be a member of listed out. The context is used with SELinux environments, in order to provide an enhanced layer of security. If you wish to view information about a different user, you'll just simply adapt the same command to include the username you're trying to inspect. We've already been seeing user information about the files we've interacted with from time to time. Using the ls -l command, we get the long listing details of a specific file. Here you can see the user01 has issued the command ls -l on a particular file in their file system. The output will correspond to the permissions for the file, we'll learn more about that later, and here we see the user that currently owns this file. While this may be getting a little ahead, we follow that with the group information as well, followed by specific information about date and time stamps for the file itself. You can see an additional output for a specific directory. Using ls -ld on a directory, will tell us, one, this first character in the permissions field is a directory, and two, who owns it for both the user and group. When it comes to inspecting processes and particularly as it relates to the system users who run them, we can use the ps command. The ps command, coupled with several flags, can be a very powerful tool in a system administrators toolkit. Here you can see we're using the command ps -au. The 'a' option in this case, allows us to view all processes within the terminal. When we wish to see the user that's executed those processes, the -u option provides that information. Have a look inside this example output of the ps command. You can see in the user column, the various users that may be running this specific process. It's not uncommon to have a process run as the superuser root, however, it's not required unless specifically instructed to do so. While the ps output shows us the names of the users who run these processes, each username is mapped to user ID or UID for the system. It's actually these UID numbers that are used by the operating system in order to keep track of the user management itself. Usernames are actually just simpler ways for us as humans to know who we are. The operating itself relies more on the numerical values of the UID. The etc passwd file which we've inspected previously, when learning our first commands on the command line, does include one line per user. When you inspect the etc password file, you can see a lot of information about the users contained within your environment. This will include all types of users. We see here some example output of one line contained within the etc password file. Let's understand what each of these fields means for us. The first field is the username itself. This is a human-readable form of the username that we are very familiar with. In this case, the username is user01. The second field typically holds only the value x. In a less secure world, many years ago, the plain text password was stored here. We can now understand that storing plain text passwords is not a proper behavior. So we have this placeholder here denoting that, the encrypted format of the file is stored elsewhere in the file system. Namely, there's an etc shadow file that contains this hashed and salted information. Next, the third field, shows the number 1000 in our output. This number 1000 is the user identification number for the user, user01. This is the numerical value that the operating system will utilize when assigning file ownership or assessing valid access when user01 tries to manipulate anything throughout the operating system. The next field is the group ID. A group ID is associated to group name, much like a user ID is associated to username. The operating system keeps track of group membership and ownership using these numerical values. In this case, the number contained in the GID field, relates to the user account's primary group. Here it's shown as the number 1000. We could inspect the file etc group to see a list of all files and their members, and understand the relationship between group ID 1000 and the group name that is associated with that GID. It's typically safe to expect that a user would have its primary group of the same name, which gets created when we create users, but this isn't required. To know exactly which primary group your user belongs to, as in this field, you would need to cross reference this information with the corresponding numerical GID and etc group. Field 5 is the real name for the user. In this case, they've typed out, "User One." This is just helpful human-readable text to describe the user who is intended here. It's most common in organizations to put someone's full length name in this field, while their username maybe some degree of abbreviated or even unrelated word. Number 6 or field 6. Field 6 shows the user's home directory. When a user logs into the environment, even remotely or locally, and opens a terminal, this would be the location that user shell is currently working from. The last field here shows the value bin bash. This is the shell value. When a user with this account logs in, the particular shell that will be presented when they open a terminal or establish a remote connection, can be changed here. By default, we use the bash shell. If it was a system user, however, that we didn't wish to have login access remotely, as that would be a bit inappropriate and even unsecure, we can use the phrase, sbin no login, meaning that there's no login interactive shell for that user.
