Now let's examine how to manage user privileges. And
every time we had to make some important changes to the system,
we used sudo in our commands.
That's because only the root user also called super user
can make changes to important areas of the operating system.
However, when we put Sudo in front of a command
that command runs as if the root user executed it.
So how come our user is allowed to use Sudo?
If we type in this command, we'll see that our user is a part of the sudo group.
Whoever is a part of this group is automatically allowed to use Sudo.
That means the easiest way to give another user SUDO
privileges is to add them to the sudo group,
to add our user trinity key to the sudo group.
We would type in this and that's it.
Now, this user can get administrator privileges whenever they want.
But this gives them power to do anything they want on the system.
What if we want more fine tuned control, then we could take a different approach.
Now there is a special file and I'll spell it out its in the slash etc folder.
And its SUD O
s like SUDOERS and it defines who can use sudo and under what conditions,
what commands they can run and so on.
But we should not edit this file directly.
We use the utility called by sudo or VBA sudo is like a combination of the two.
This utility can check to see if our edits are
correct to help us avoid mistakes in this file.
First,
let's remove trinity from the sudo group to make sure she can't use Sudo anymore.
And instead to find a different sudo policy for her later
to start editing the Etsy Sudoers file.
We're just run Sudo by sudo
and it opens up in the vim editor.
So this file is thoroughly commented,
but we're not interested in the first few parts.
So let's navigate to the end.
You will notice on this line
that allows people in group sudo to run all commands.
Now, we see why any user added to the sudo group can run any command with Sudo.
Let's break down this line into the five different parts and analyze what they do.
Number one, this is the users group here, we define who this policy is for.
Number two is the host here,
we can specify that these rules only apply if
our server's hostname or IP address has a specific value
not really useful for our purposes. So we'll just type in all for this field.
And the next is the run as user field.
Now, here we can type in a list of usernames.
Normally, sudo, LS will run the LS command as root because that's what sudo does.
It runs the command as a different user
and by default, it runs it as the root user.
But sudo can also be used so that Aaron
can run commands for some other regular user like Jane
and we'll see more about this later.
So if we list Aaron Jane, etcetera in this run as field,
then sudo can only be used to run commands as user, Aaron or Jane but not root
in these fields. We want to specify multiple values.
We just list them one by one separated by commas.
This is the run as group field and it's the same as before.
If we type all here,
then users that belong to the sudo group can use Sudo to run commands as any group.
If we type a group name,
then they can only run commands under the group that's listed here.
And five, this is a list of commands that can be executed with sudo.
So we could say that the syntax for a policy defined in the Sudoers file is this
now let's go through some examples
to define a policy for our Trinity key user and let her run any sudo command.
We can type in something like this.
And we can see in this case between the parentheses, we just specified
Trinity can run all commands as all users.
But we did not specify any groups.
This will mean implicitly that she can run commands as any group to
even if we didn't add the second all field here
to specify a policy for all users in the developer group,
we just add the percent sign in front of the group name
and this will include all of the people in the developers group.
We mentioned that sudo lets us run command as root but also as nonroot regular users.
For example, to run LS home Trinity command as the user called Trinity,
we could write something like this.
After the dash you, we specify the username, we want to run this command as
if this third field is all,
then this policy allows someone to run SUDO commands as any user.
But if we want Trinity to only be able to run sudo commands as the users, Aaron or John,
we would write this.
And also this is wrapped in parentheses which hints that the field is optional.
So a line like this
is also valid.
We mentioned that in the fourth field, we can specify a list of commands
with our previous entries.
The user or group granted sudo privileges can execute any command
but we can live with them like this.
Now, Trinity can run commands such as LS or Stack
and only the LS or Stack commands will work.
If Trinity key tries a different commands such as this,
she will get this error.
And since we specified the third field is optional,
this line
could also be written like this.
We know that the first time we run a SUDO command in a session,
it asks for our current user's password
in our sudoers file.
We see a hint about how we could get rid of this kind of requirement.
So we could use this example in the comments
and figure out how to apply this for our user trinity.
If we want to be able to run SUDO commands without providing a password,
we can write in this line into the sudoers file.