In this video,
you're going to learn about the privileges
that a superuser has in order to create accounts
for other users,
as well as perform many other administrative tasks
that we're going to discuss later throughout this course.
Now anyone who's using a Linux computer
should always have their own unique user account.
These user accounts are usually set up by an administrator,
and these accounts control a user's access to files,
directories and commands on the system.
Each account is going to be referenced by the system
using a UID or user ID
rather than a person's actual name.
Now there are three different types of user accounts.
We have the root account,
we have the standard user
and we have a service account.
The root user account plays two roles on a Linux system.
The first role is that of the local administrator.
A user logged in as root can do administrative tasks
such as password resets,
system configuration changes,
user account management and so much more.
The second role played by the root user account
is to provide a security context
for some applications and commands to utilize.
These applications and commands may be called
by the system or manually entered
by a user logged in as the root user.
The root user account in Linux
is significantly more powerful
than a local administrator account
on a Windows system though.
So you need to be careful with it.
For this reason,
it is extremely bad as a security practice
for you to log on to a system as the root user
because if you're using those administrative credentials,
it can take destructive action on the system
and this can be usually irreversible.
For example, if I was logged in as the root user
and I enter the command rm-rf/*.*
and I do that at the command shell,
this is going to delete every single file
on your system's hard drive
and nothing is going to stop me.
Seriously, when you're logged in as the root user,
you have to know what you're doing
and you have to be really careful.
Next we have standard users.
Now a standard user represents a regular system user
who can log on to run applications,
configure databases, build websites
and do other normal tasks.
Each user should have their own account
and these accounts should not be shared with anybody else
to ensure the security of your systems.
Also, most tasks that a user should be doing on the system
will only require standard user account privileges.
Now, it is possible to set a standard user account
to have administrative privileges.
The advantage of doing this over permitting the user
to log in as the root directly,
is that the privileges of the standard user
can actually be limited,
whereas the root privileges cannot.
This is the execution of a security practice
known as least privilege,
where we give users only as much access as they need to
in order to perform certain job functions.
Now, the third type of account we have
is called a service account.
Service accounts are usually specific to the service
such as the HTTP daemon for web service
or mySQL daemon for database services or things like that.
Now, the key thing about these service accounts
is that they're not set up for interactive login.
This means they're disabled
for a regular person to log onto them.
And these accounts are usually going to be created
as part of the service installation process instead.
They're essentially just going to run in the background.
They're often going to own the configuration files
or executables that are associate with a given service
like the Apache Web Service
or the mySQL database service.
Service accounts basically are going to run in the background
and perform a single function.
Like one account may be the printer service
that runs the printer daemon.
And this allows all the users to access and print
to a shared printer or something like that.
Now in Linux the user with administrative credentials
is known as the superuser.
And I told you, the superuser is typically named root.
But you can really rename this to anything else you prefer.
As I said earlier,
it is generally considered a bad security practice
to log onto the system as the superuser.
So you should always log into the system
with your non-privileged user account first.
Now I know you've heard me say that a few times already.
So guess what that means,
it means it's really important
and something you do not want to forget
between now and exam day.
Do not log in as the superuser.
Bad, bad things to do.
All right.
Sometimes you're also going to find there's instances
where the superuser's account permissions are needed
in order to perform an administrative function
such as managing users,
configuring devices and configuring network settings.
To do this, we need to elevate our privileges though.
In information security,
the principle of lease privilege
states that users should be given no more authority
on a system than they need to perform their job.
If a user needs to be able to read a file
but not write a file,
then give them only read access.
If a user needs to be able to restart the server
but not reconfigure the server,
then only give them permissions to restart that server.
By giving the user the access they need to do their jobs
and know more than that the system will remain
much more secure.
So, since I said it's a bad security practice
to log under the server directly as the root user,
what can we do instead
when we need to perform functions
that need the root user's permissions?
Well, the best practice here
is to log on with your standard user account
and then elevate your permissions to root as needed.
One way of doing this is to use the SU
or substitute user command which is entered as SU root.
Personally, I like to think about the SU command
as the switch user command
because it helps me remember what the purpose of it is.
So if you hear me say switch user
instead of substitute user throughout the course,
that's just my memory aid.
And that's what I use when I'm typing in something like SU.
It helps me remember what I'm doing.
The SU command will allow you to switch the user credentials
and the su-root will switch the credentials
to that of the root user.
The system will then prompt you
to enter the root user's password
for authorization purposes and if you get it right,
you'll be logged in as the root user
and you can perform whatever task
you need to on that system.
Now, rather than granting system wide privileges,
it's a much better security practice
to delegate specific functions to a user.
The sudo command or S U D O ,
is going to enable the server administrator
to delegate specific commands to specific users
without grading them full privileges on that server.
To provide delegation to a user account,
you need to list the user in this sudoers file
which you can find in the /etc directory.
So you'll find it at /etc/sudoers.
This file can only be edited using the text editor
V I S U D O which is the visudo editor.
By doing this,
a user or a group of users
can be given specific commands to run
in order to fulfill their responsibilities
without having the full administrative power
of the root user.
Now, there are some Linux files that require the root user
to be able to edit them.
The sudoedit command,
permits a user to edit a file with their own credentials,
even if the file is only available to the root user.
In addition to this,
the user can also use their preferred text editor
if they want to.
But to use the sudoedit command,
you must make an entry in the sudoers file for them.
For example, if you add percent editors,
all equals sudoedit/path/to/file
as one of the lines in your soudoers file,
it's going to allow any member of the editor's group
to edit that file by using the command
sudoedit/path/to/file.
To ensure the security of the sudoers file,
it's essential not to edit the /etc/sudoers file
with a standard text editor like vi(m) or nano or gedit.
Instead, you should always use the visudo command.
This way, the system can verify the syntax
of the /etc/sudoers file before it commits any changes
and it enables the administrator an opportunity
to correct any mistakes before they become
part of the running configuration.
Some options that you can use with the visudo command
are the -c, -f, -s and -x options.
The option -c is going to be used
to check the existing sudoers file for errors.
The dash -f option is going to be used
to edit or check a sudoers file
in a different location than the default location.
The -s option is going to be used
to check the sudoers file in strict mode.
This means that any other name
that's being used before being defined,
is going to result in errors.
Finally, the -x option is going to be used
to output the sudoers file to the specified file
in the JavaScript object notation
or JSON formatted file type.
Now many distributions will disable
the actual root account for users
and instead it allows administrative functions
based on membership in what's known as the wheel group.
Now members of the wheel group
are going to exercise the administrative privileges
of the root user with less potential
for damaging your system.
For example, members of the wheel group
can use the sudo command to avoid having to sign in
as the root user.
You can also use the visudo command
to edit the privileges of the wheel group if you need to.
You can also add users to the wheel group
to give them privileges as well.
CentOS, which is the operating system
we're using in this course,
does like to rely on using the wheel group
instead of logging in as the root user.
Another tool to be aware of is known as polkit.
Polkit was formally called PolicyKit.
Now polkit is a component in Linux systems
that controls system wide privileges
in organized way that allows non-privileged processes
to communicate with privileged ones.
Up until 2012,
this feature is actually called PolicyKit.
And that's what it's actually referred to
in the exam objectives has,
but it is more accurately called polkit
and that's what you'll hear called in the workplace.
Now polkit allows a command to execute
with elevated privileges using the command pkexec
followed by the command you want to execute,
much like the sudo command does.
Now for example,
let's say you want to make a directory called Jason
underneath the root directory of your file system.
You need to use root permissions to do that.
So you could enter pkexec mkdir/Jason
and this would then create the Jason directory
using the root user's permissions.
In general though, you're going to see that most administrators
prefer to use sudo to execute a command
with the root permissions,
instead of using pkexec.
And this is because sudo is easier to use,
it's more flexible and it tends
to have a better security posture
than using pkexec in a given system.