And yes, it's demo time again.
We're going to take a look at creating sudo entries,
and we can see how we can do our syntax checking and
delegating tasks to our users.
Come on, let's find a command line.
And here we are, welcome to the command line of my Vagrant system.
It's the Alma Linux 8 that we are working on for these demonstrations.
We've already created our user account, bob,
but, as yet, we haven't set a password,
so let's make sure we've got a password for the user account.
We can go through and do it quite easily.
We can use the echo command. Echo out our password. So let's just
keep it simple, I'm setting it to Password1.
And we can go through and pipe this to the sudo and passwd command ‑‑stdin,
so we're reading the password from standard in.
We have this option on Enterprise Linux,
but we don't have it on Ubuntu by default.
It's not on Debian‑based systems.
And this is then for the user bob,
but it then saves me having to type the password out twice.
So it becomes an easy way that we can build in with a standard passwd command.
Also for the demonstration, we're going to be making use of another user account,
so we can go through and run sudo useradd ‑m to create the home directory,
and let's say our tux user.
With our tux user created, we again can go back and set the password.
This time, it's just going to be obviously for the tux account.
So with that done and dusted, we're ready to go with our user accounts.
If I want to give rights and let's say we want full
administrative rights for the bob account,
then we can go through and edit the sudoers file.
If I go through and just look at it, so sudo and less,
we can page through it, and we're going to find it in etc and sudoers.
I don't have access to it without elevating my privileges,
but as we then go through, we can see there are a lot of comments,
but then it shows me some of the things that can be configured.
If I wanted to read it without the comments,
I can then go through and do a sudo grep ‑Ev to reverse our search.
We can go through and specify that we want to or not look at because we
are reversing lines beginning with and then a group.
This is why we've used the uppercase E.
And we can say then beginning with a comment or an empty line,
so starting with $, the end of line marker from our last argument,
so we're only looking at the effective settings.
Now all of this is good, and we can see how some of it can work,
and we've got privileges that have been set up for the root
account and the wheel group by default.
If we wanted to add an entry, we could add it to this default file,
and we'll look at this to begin with.
So if I go through and look at now sudo and visudo,
now the importance of using visudo is to ensure that we do a syntax check,
and I will show you this at the end.
If I don't specify the name of the file, it opens up the etc sudoers file.
It opens up in the default editor, which is vi.
I'm going to use uppercase G to move to the end of the line, and we can see
towards the bottom we include the sudoers.d directory.
Now let's be daring and add in a new entry.
Doesn't really matter where we add it,
but I'm going to add a new user entry just below the entry for the wheel group.
I'm adding an entry for the bob user.
Using ALL, I'm really implying that bob could use this on all systems,
although this is just for the system that we are working on,
so this Alma Linux system.
We can go through and specify that he could potentially sudo to all users,
and we can then duplicate the entry that we have above.
Now if you look at this, I've deliberately made a mistake.
We can compare this to the entry of the wheel group,
and I don't have the equals symbol.
As I go through now and save my change,
we're getting this warning saying we've got a syntax error.
Now this is really important.
When we look at the options, I can edit the file again.
That's a good option.
I could exit and don't save the changes.
That, too is a good option.
But quitting is a dangerous option, as it's marked.
I really do not want to do that.
It would break my complete sudoers system.
So I'm going to choose to use the e for edit,
and I do encourage you to read very,
very carefully the options that are available to you.
The (Q)uit option should never be there.
It's not a viable option.
So I'm going to use lowercase e to edit,
and I can correct the entry by putting in the equals
symbol between the ALL and the parentheses.
And then saving my file again, we're back up and running.
So we don't get the syntax error now on closing it.
Now, in general, we should avoid writing to our main sudoers file,
that's really an example file with defaults.
However,
we're encouraged to create our own plugin files inside of the plugin directory.
We can do that, again, using the sudoers command.
But remember,
the sudoers command visudo is going to open up in the default location.
To specify a different file, we use the option ‑f,
and I navigate through to the etc and sudoers.d,
and I can create an entry for my user tux.
In here, as we go through, again,
we're going to be specifying a user name rather than a group,
so we don't have the percent.
Again, we can say from ALL systems,
but I could just put the Alma Linux system if I want.
The only system this really applies to.
We're specifying he can only sudo as root.
That's quite sensible really.
And we're specifying the keyword NOPASSWD followed by a colon,
so all commands that follow this will not require a password.
So we're using the passwd command, or he can use the passwd command,
but not, the exclamation mark means not,
usr/bin/passwd with the argument of root.
So we can't change the root user's password.
Now with this in place, I can go and save those changes,
but we need to go through and check that the changes that we
made work both for the bob and the tux user.
So let's do then a sudo su to bob.
We can then go through and check what bob is allowed to do with sudo ‑l.
Notice that he's being prompted for his password.
And we can see towards the bottom of the output,
that he is able on the Alma 8 system, to go through and run ALL commands.
Well, that's all well and good for bob,
so let's exit out of this and try something similar,
but this time let's go through to the tux account.
Now when we go through and use our sudo ‑l to list what we're allowed to do.
On this system, we can see that we're not being prompted for a password,
which is good.
And then it shows me again that I can run the passwd,
but not with the argument of root.
So let's go through and check this using sudo and passwd.
I should be able to go through and change the password for the bob account.
So let's try this.
And as we go through,
it's allowing me through the prompts. We've changed the bob password.
Let's try it again with the root account,
and we get this warning straight away that we're not allowed to do it.
Our security is working,
and we can see then using sudo that we are able to delegate commands, not just allowing full administrative rights.