CHAPTER 17. Control Privileged User
At this point, it is time to begin discussing the security and privileges of users that can access your OS or server. Especially today, people seem to think that technology and servers are less safe than ever, but contrary to popular belief, there is actually plenty of support available to keep systems safe and secure. One such way is through controlling privileged users, which this chapter will teach you to do.
In reading this chapter, you will be guided through various types of linux accounts, such as the root user, normal user, and system user. You will discover sudo, which stands for the super user do. This is the command for the system admin—it is the one command that allows access to everything and anything, so long as you are on the right account with the proper privileges to use it. Lastly, you will be walked through the sudoers file. This file is essentially the underlying programming behind the sudo—it controls the sudo and who has access to the sudo command in the first place. 
All of this will help you juggle the users on your server or machine, allowing you to ensure that the proper security systems are in place. With everything in place and a secure system, you are able to rest easy and feel like your system is truly safe. 
Types of Linux Accounts
First, we will be discussing the root, normal, and system users before progressing to anything beyond this. You must have a complete understanding of these three user account types to really understand how sudo and sudoers play into the security of the system.
Because Linux is so incredibly flexible, you have the option to create several different types of accounts. In fact, you can have several root accounts if you need them, or accounts with different permissions in different categories. All that matters is that the needs you have are met effectively. 
Keep in mind that just because you have root accounts does not mean that you should not have some sort of security system in place—you should absolutely have a password protecting the root accounts to ensure that no one else is ever able to access those files and overtake them without your permission at all. This means that you will be able to ensure that the files themselves have yet another layer of protection. Now, without further ado, 00013.jpeg let’s begin to dig into the three primary user types of Linux.
Root user
The first user that you must know is the root user. This is also commonly referred to as the super user, especially in the acronym sudo. The super user or root user is the individual that is on the default admin account. This person has full control over the system, much like how an administrative account would have control over Windows. With the root privileges that are given by default, this user is able to execute any of his or her commands and directly control or alter the services and accounts of other people.
Effectively, this should be your account if you are the one setting up the system. This account is the one that is able to rule over the other accounts, managing and monitoring them all without need for extra permissions. All permissions are granted for the root user. They are able to change the permissions of other users, move files around, change the ownership of files, and do anything else within the system.
Keep in mind that, because you have the power to do literally anything within the program, you will not have the OS telling you not to do something. There is no safeguard for you, and you must be careful when using this account. If you delete a system file, there may be no hope for going back if you have not been regularly keeping archives and backups of your file. If there is a user that is capable of doing catastrophic damage to your program, it is the super user or root user. 
Linux assumes that the root user has a pretty good grasp over what they are doing, and because of that, if you are unsure of what you are doing at any point in time, it is better safe than sorry, and you should try reaching out to someone else for help if you think it is necessary. Overall, while this should be your account with your own privileges, you should also try to avoid this account as much as humanly possible in order to ensure that you are not risking destroying everything at all.
There are very specific periods in which you should use the root. Otherwise, you are likely going to be fine with just a normal account for most day-to-day functions. Of course, any time that you are attempting a task that requires you to a user the root, you should make sure that you switch over as necessary and back up your data before attempting anything. In particular, you will need to use the root privileges in order to move files or directories in or out of the system directories. Remember, the system directories are those that are directly responsible for the functioning of the operating system, and without them, you cannot run the OS. It is also necessary when you are attempting to copy any of the files into system directories, when altering the user privileges of other users, for some system repairs, and the occasional installation of a program will all require you to use the root account. Typically, if a file needs root permission to be installed, it is because the file itself will be directly interacting with the system directories.  If you are not doing any of the above, just avoid it and save yourself the hassle of potentially messing up. 
Normal user
The normal and system users have the same privileges, and both are typically created by the root or another user who has been granted some level of sudo privileges .The normal user, however, is normally a real person, while the system user is typically a user reserved for software to utilize if necessary.
The normal user will have a real login shell and its own home directory, and each user will also be assigned a UID—a user identification. If this went unspecified during the creation of the new user with the useradd command, then the UID is typically automatically selected for you.
Essentially, however, this user does not have any super special admin powers or superuser status. The normal user is able to access any files that have not been otherwise marked as unavailable, and the privileges of the normal fire can be changed regularly depending on what is necessary for the user at any given time.
Most likely, if you are running Linux on your own device, you will have a root account, the administrative account that was used to set up the entire OS, to begin with, and then you will also set yourself up with a normal user account to ensure that you do not accidentally delete something critical or destroy something important. This is your sort of safeguard against an accident.
The normal user’s own permissions can be customized by the root user—you can grant yourself any permissions that you desire on the normal account from the root account, so long as you know the right way to code it. 
System user
The system user, as briefly touched upon, is granted the same initial privileges as the normal user. However, the system user is almost always some sort of software or program, such as a daemon, that will be running in the background and will likely not be particularly interactive. This user classification primarily exists just for organizational purposes. When you are able to dictate the account as a system account, you know at a glance that it is not going to involve any sort of people interacting with it. There may be a daemon running the user, but no person will ever belonged on.
While in the real world, this may not necessarily matter technically, it is nice to be able to see at a glance how many human users you have as opposed to daemons running specific software. Usually, these system accounts are created by the operating system during installation, and the OS retains their control. They usually have very specific user ids that you can identify within the root account. 
Because these service users will be running processes necessary for the OS, they should be left alone when you are altering, ending, or resetting any processes. You want to make sure you leave these service users alone as much as possible to protect yourself from damaging the software. If you were to damage one of these, it is quite possible that you would destroy the entire OS, which is unfortunately easy to do if you are not paying attention.
Sudo
Now, it is time to discuss sudo. If you are using sudo before a command, you essentially push it up. You tell the system that you are commanding this particular process with elevated privileges that should be respected. Usually, the elevated privileges are what the system checks to ensure that you are actually granted the privilege to make any alterations that you are actually making. 
If you have been using Windows primarily, you already have interaction with a sort of example of this account. When you install software, have you noticed how certain installations will trigger a prompt to pop up and ask if you are certain that you wish to proceed and ask for you to give the software the permission it needs to proceed? That is what you are doing in Sudo. You are effectively giving that permission, but instead of with a click of the button, you are telling the system that you have elevated access to the system and should be respected. 
If you have been primarily using macOS until now, you have a similar sort of safeguard when you trigger downloads that may be recognized as dangerous or will create major alterations to the OS. On a Mac, you will see a security box pop up, and you must then provide the system with your password to confirm that you do, in fact, want to perform that change on the system.
Effectively, then, Sudo is your privilege pass. It is the magic passphrase that tells your system that you are in charge—so long as the privileges on your user account match.
Using Sudo
When you are ready to use Sudo, you do not have to try very hard. Effectively, all you have to do is add sudo before the command that you are trying to push forward. If you do this, your program should then ask you for the account password for the account that you are on. If you provide this password and your credentials check out, it will perform the function.
For example, imagine that you want to reboot your system. As you may recall, the command to trigger your system to reboot is simply reboot.
However, reboot requires sudo privileges. If you were to simply try commanding your system with just reboot, it would tell you that you must be a superuser in order to execute that particular command. 
That is where you would then escalate your command. At that point, you can add to your command, creating an input of:
$ sudo reboot
Your system then asks for the account password, and upon entering the password, it reboots as requested.
Su instead of sudo?
This is perhaps one of the safest ways that you can use to elevate your privilege to trigger the system to obey. There are others, such as the switch user command, known as “su.” However, when you use the switch user command, you are asked for the root password and then given the superuser prompt.
You know that you are in the superuser prompt when you get a # as your input ready signal instead of the typical $ that you are likely used to seeing by now. The # should be your warning sign—if you see this waiting for you in the terminal, you know that you are on the root account, and you need to be careful.
While the switch user command may have its uses in very specific situations, it also runs the risk of you destroying everything with a single typo or the act of someone accidentally bumping you while you are clacking away at your keyboard. When you use sudo, however, you are required to insert it for each and every command that requires extra privileges. This means that you have that extra safeguard. Of course, this could get annoying if you were in the process of doing something that would require you to constantly be validating your credentials, but it could be worthwhile if you think that the extra security is worth it. Of course, you could always just set up a backup of your system right before you begin the process of entering your su commands if you wanted to bypass the constant sudo usage, but that is ultimately a personal decision that you have to make, weighing the risk for yourself. Ultimately, the more you are in su, the more likely it is that you are going to have an accident. 
The Sudoers File
Underneath sudo is the sudoers file. This determines who gets to use the sudo command in the first place in order to actually make use of the authority it brings with it within the OS. Typically, you can access this file within the location of /etc/sudoers, and you will have to edit this if you want to mess with command values and permissions. Perhaps the best way that you can make user of the sudoers file and the safewst way to editing it is thorugh using the visudo editor.
Visudo
Visudo itself acts as a sort of stopgap—an extra layer of security for the sudoers file. It allows for safe edits while also locking the sudoers file from being edited at the same time by multiple users, which could become dangerous if two people tried to create contrasting edits at the same time. If you try to access the sudoers file with visudo when someone else is currently in it, you will be rejected with an error message and told to try again later. When you do make an edit, it will stop and check the edits for any errors that may be catastrophic in an attempt to at least try to make sure that you do not completely destroy something important.
Upon finishing your edit of the sudoer file after accessing the visudo editing system, the edit will be scanned for any errors. If you do happen to make a syntax error, it will reject the save, printing the message that declares that there is an error and will tell you which lines that mistake is in. From there, you are prompted to either attempt to re-edit to fix the mistake, or you can quit saving the changes anyway. However, if you quit after visudo has found an error, it is highly likely that sudo will also find the error, and sudo will not be accessible until the error has been corrected.
In order to access visudo, all you have to do is enter the prompt:
$ visudo
and you should be granted the access you are looking for, so long as the permissions are right. There are also several other options that you can pair with the visudo function in order to help you really make the most out of the program. These commands include:
visudo -c: This triggers visudo to go into a check-only mode. It will check the current sudoers file for any syntax issues and will print the status of the file. If the check was clear, visudo would end with a final value of 0. However, if there is any sort of error detected, it will end with a value of 1. 
visudo -f sudoers: This specifies an alternate location for sudoers, checking or editing the file of your choice instead of storing it in the default /etc/sudoers. 
visudo -h: This is the help option, and when you do this, visuo will provide a short printed message.
visudo -q: This tells visudo to enter quiet mode. When in this mode, no details of the syntax errors detected during a search will be printed or pointed out to you.
visudo -s: This will enable the checking of the sudoers file. It will create an error if an alias that has not been defined is being used.
visudo -v: This is the version option—it tells visudo to print out the version number before quitting. 
The sudoers file
With the visudo access created, you are then able to begin editing your sudoers file. This is what will provide the sudo access to any accounts. When you first access your sudoers file and scroll to the bottom, you will likely see a line that says something along the lines of:
root ALL=(ALL) ALL
Effectively, this means that the root user can execute from all terminals, like all users, and run all commands. Read all as any for a moment, and you can see how that can be scary. The root user can be basically anything it wants to order anything it wants and do anything it wants. 
If you want to have any similar powers yourself on other accounts, you will need to set yourself up for an account that is designed as a sudo account.
First, you must log into your server as the root user. 
Then, using the command adduser you must create a new username.
$ adduser usernamehere
At this point, you will be asked to make a new password for the account. Do not forget your password, and make sure it is actually secure. From there, the command will create a home directory for you. Just press Enter to accept the default unless you feel like filling it in.
Then, you must add the new user to the sudo group using the following command
$ usermod -aG sudo usernamehere
This should give you the sudo access, though you should still probably test it. Switch to the new user with the su command:
$ su – usernamehere
At this point, you need to test your access. Try using the whoami command to get all of your details:
$ sudo whoami
If done properly, the command will provide the output “root.” If it is root, you know that you have access.
From here, all you have to do is use the sudo command with space after it before any command you issue. The first time you attempt to use sudo when in a session, you will be asked to enter your password for security reasons.
And just like that, your user account will have sudo access, allowing you to avoid any painful mistakes that could cripple your system or ruin your files in any given way. Since you will now have to enter sudo in order to do anything significant or dangerous, you should be pretty secure.