As root, we need to edit the
/etc/sudoers file by running
visudo (NOTE: You can
export EDITOR=vim to get syntax highlighting, or use the editor of your choice).
Around lines 83,86 you should see two lines that are similar (in vim you can run
:set number to show line numbers):
83 # %wheel ALL=(ALL) ALL
85 ## Same thing without a password
86 # %wheel ALL=(ALL) NOPASSWD: ALL
The difference is that line #83 will require the user to enter their password to authenticate, whereas line #86 will allow the user to
sudo without re-prompting them for their password. Best security practices state that #83 is more secure; however depending on your situation #86 can be appropriate (for example I generally use #86 while setting up a server then switch to #83).
Exit and save that file.
Now we need to tell the system which users are allowed to escalate their permissions via
sudo. This is done by adding them to the
wheel group, that is what the
%wheel indicated in the
sudoers file we edited earlier. See
man sudoers for more information on that file format.
$ usermod -a -G wheel erebusbat
That command will add the user
erebusbat to the wheel group, combined with our earlier change would all them to run any command as root:
erebusbat@centos$ sudo whoami
X / GNOME Setup
In CentOS/RHEL 5 and below the X authentication is handled by a set of programs called
userhelper. Basically what happens is this: when a user executes a program (say
pirut) it checks to see if there is a files called
pirut in the folder
/etc/security/console.apps/ if we look at one of those files it looks like:
userhelper to allow the user to authenticate and run the program as root. If we
man userhelper we see that we can add a
UGROUPS= directive so that if a user were in that group they would be allowed to authenticate as themselves, but run the application as the user specified in the
USER= directive. So out
pirut file needs to look like:
As soon as we make that change whenever we attempt to run
pirut as a normal user (Add/Remove Programs from the GNOME Menu) one of two things will happen:
- We will be prompted for OUR password and the program will launch as
- We will be prompted for
root's password if the current user is not in the
However changing all those files by hand can be a PIA, so we work smarted and not harder:
$ cd /etc/security/console.apps/
$ sudo su -
$ pcregrep -ML '^UGROUPS=' * | xargs sed -i 's/^USER=root/USER=root\nUGROUPS=wheel/'
sudo su - command is not needed if you are currently
root. The command will not 'double fix' any file so it can be
chroned or set to run on startup to make sure your files are ok. Updates and installs can overwrite them or create new ones that do not have the
Disabling root User
Once that is all setup and tested you should disable the root user:
$ sudo passwd -l root
That is a lowercase L, as in LOCK.
Then you should set or change
PermitRootLogin no in your
/etc/ssh/sshd_config file. This is useful even if you lock the root account, in case anyone enables it in the future.
sudo su - will still work even if you set this, see below, so there really is no reason to not set it.
If you decide to not lock the root account it is not ideal as anyone can login to the text/X/GNOME console as
root and that is when bad things happen (the console stays logged in or you accidentaly delete a bunch of OS files [ask me how I know], best to lock the account.
Running as root for extended periods
Sometimes, such as software installs, it is necessary to run many commands as
root and not desirable to have to prefix each with
sudo. You have two options in this case:
- Temporarily switch to the
$ sudo su - That command will give you the same command shell as if you had logged into the account as root.
- Unlock the root account:
$ sudo passwd root This will allow you to set a password and unlock the account; however it is not temporary and you must remember to lock the user account after you are done.