Let's explore the sudo configuration a bit.
So sudo configuration is managed through etcsudoers.
You should never edit this file directly, only edit it
through the visudo command.
And instead of editing etcsudoers directly,
you can also consider creating drop-in files in etcsudoers.d.
So this is a generic thing that you
will find in many cases in Red Hat Enterprise Linux.
Don't edit the main configuration file.
Instead of editing the main configuration file,
you need to create a drop-in file in etcsudoers.d
in this case.
And that is because etcsudoers is installed from packages
and may be overwritten.
And drop-in files will never be overwritten.
Now, how do you normally provide administrator access?
Well, users that are a member of the group
will get full sudo access by default.
And this is accomplished by the %wheel all
is all line in etcsudoers.
So if you want to give a user full sudo privileges,
use user mod minus lowercase a uppercase G wheel my user
to add the user my user to the group wheel.
That is definitely the easiest way to give full sudo access.
Don't ever enable the line %wheel all
is all no pass wd all because that will provide full sudo
access without entering a password.
It is very dangerous.
There are more sophisticated ways to do so.
If you don't like entering your user password every five
minutes, then you can increase authentication token expiration
by adding the following line to the etcsudoers.
So timestamp type is global and timestamp timeout is 60.
What is this about?
Well, when you are prompted for your sudo password,
after entering your password successfully,
a sudo authentication token is generated and stored
in your environment.
But that token expires.
And the expiration by default is set
to just a couple of minutes.
And by using timeout equals whatever you want,
you can set it much higher.
60 if you think that one hour is reasonable,
or 240 if you want it to be four hours in total.
Everything is possible as long as you have
thought about it the right way.
You can also use sudo to provide access to specific tasks.
In order to do so, you can use drop-in files
to provide admin access to specific tasks.
Like lisa all is sbin user at user bin pass wd,
which means that user lisa can use user at and pass wd
as root, and that's all.
You can make commands like this more specific.
For instance, %users all is bin mount dev sdb
and bin unmount dev sdb, meaning that if you
are a member of the group users, you
are allowed to mount, but only the device sdb and nothing
else, and you mount it as well.
Or linda all is user bin pass wd,
but exclamation mark, which generically
has the meaning of not, user bin pass wd root,
meaning that user linda can set passwords,
but not for the user root.
Let's have a look at this configuration.
All right, I'm going to use sudo vi sudo.
Now I'm going back to my root shell.
Again, folks, might not be something
that you want to do in real life, but on your RHCSA exam,
most things require root privileges,
so you're probably much better off in a root shell.
So I'm going to use vi sudo to open the sudoers configuration.
It starts with a lot of stuff that most people never use,
so I'm going to use uppercase G to go to the end
to show you a couple of items that I want to show you.
Here we have the line that makes it
if you're a member of the group wheel,
you are allowed to run all commands from all systems
using all identity.
By default, that means that members of this group
can run tasks as root.
Now I would like to add a line
that creates helpdesk user Linda,
and I'm moving just above the line
that says percent users all has been mount
because that's a nice example line
that shows what is going on.
Percent users means members of the group users.
Well, I don't care about members of the group users.
I want to do it for Linda and for nobody else,
so I'm using all is slash user slash bin slash pass WD,
comma exclamation mark slash user slash bin
slash pass WD root.
User Linda is allowed to change all passwords,
but not the password of user root.
Now that we are in the sudoers configuration,
I also want to set another default value.
I like having my default values all together,
and you can have multiple lines that start with defaults.
So timestamp underscore type is global,
and timestamp underscore timeout is 240.
Why 240?
Well, that means that my authentication token
is valid for four hours.
So if I come into work in the morning,
I enter my sudo password once.
Then I go lunch, and after lunch,
I need to enter it again.
Again, the number is the number of minutes.
Use anything that you would like to use.
So I'm going to change my configuration here,
and oh, no, I made a typo.
I did that on purpose because I want
to show you what is going to happen if you made a typo,
and this is why you need sudo to be edited using visudo
because otherwise, if you make a typo,
that would deactivate sudo, and if you don't have access
to sudo anymore, then you have some pretty complex
troubleshooting in front of you.
So what now?
Well, I'm pressing Enter, and there I
can see that I can use edit sudoers file again.
And what do I need?
Not timestamp time is global, but timestamp type is global.
Do you see that the VI syntax highlighting is also
kicking in and helping a bit?
And this time, I am completing it successfully.
So now I want to test.
Let's first test this useLinda thing.
The other thing can't really be tested
because we need to generate a new timeout token,
and we will only see four hours later if it worked out
successfully or not.
So I'm using su-linda with a space
on both ends of the minus.
Notice that I can do that because I'm user root.
If I wouldn't be user root, I would get a prompt
for useLinda password.
Now, if a non-root user would do this,
then the non-root user could always
use sudo su-linda to take the identity of useLinda.
And oh my goodness, what do I see?
I see that useLinda has a misconfiguration.
I have changed the shell to ZSH.
OK, I'm really going to show you this in the next lesson,
but let me change it now.
userMod minus S bin bash for useLinda.
That should fix it.
It redefines the default shell, and now you
can see that I'm in the useLinda environment.
So useLinda is going to use sudo user add Lisa,
and well, on first sight, nothing is wrong.
So it's telling us, hey, you need to be careful
and enter your password, and uh-oh, password for Linda.
Sorry, try again.
What's going on?
Well, do you remember that we have ever set a password
for useLinda?
We did not.
And useLinda, really, if she wants
to use her sudo superpowers, needs to enter the password.
So I'm going to Control-C this because this is not
going to work.
useLinda doesn't have a password.
And also, I can't set it for useLinda.
I need to get back to my superuser shell
where I can use passwd Linda.
If you do this as root, you are just
prompted for the new password, and you don't
have to know the old password.
If you would do it as useLinda herself,
then you first need to enter the old password
before you can enter the new password,
and that is not going to work.
So now the password is updated successfully,
and I can try it again.
So back to useLinda shell, and back to sudo user add Lisa.
And password for useLinda, and oh, boy, there we get useLinda
is not allowed to execute sbin user add Lisa.
That's right, because we have only allowed useLinda
to use the passwd command.
So sudo passwd student, is that going to work?
Well, Linda first needs to authenticate
with her own sudo password, and then she's
prompted for the new password.
You can ignore the bad password message
here, because useLinda is using her sudo superpowers.
And using sudo superpowers, you don't
have to use a secure password.
You should be able to set a temporary password.
And now we can see that the password updated successfully
for useLinda student.
Now, how about doing this for useRoot?
Well, there we get immediately that useLinda is not
allowed to execute bin passwd root,
and that's exactly the way we wanted it to be.