Weblog
Thoughts which doesn't affect the world's peace

using sudo

Using “sudo” instead of “su” for gnome desktop applications is not really hard to do, but it took me a while to find and understand the way to do it. Here is what I found in a serverfault.com

Terminal Setup

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):

1
2
3
4
83 # %wheel ALL=(ALL) ALL
84
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.

1
$ 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:

1
2
3
erebusbat@centos$ sudo whoami
root
erebusbat@centos$

X / GNOME Setup

In CentOS/RHEL 5 and below the X authentication is handled by a set of programs called consolehelper and 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:

1
2
3
4
USER=root
PROGRAM=/usr/sbin/pirut
SESSION=true
KEEP_ENV_VARS=http_proxy,ftp_proxy

This tells consolehelper/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:

1
2
3
4
5
USER=root
UGROUPS=wheel
PROGRAM=/usr/sbin/pirut
SESSION=true
KEEP_ENV_VARS=http_proxy,ftp_proxy

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:

  1. We will be prompted for OUR password and the program will launch as root.
  2. We will be prompted for root‘s password if the current user is not in the wheel group.

However changing all those files by hand can be a PIA, so we work smarted and not harder:

1
2
3
$ cd /etc/security/console.apps/
$ sudo su -
$ pcregrep -ML '^UGROUPS=' * | xargs sed -i 's/^USER=root/USER=root\nUGROUPS=wheel/'

The 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 UGROUPS= directive.

Disabling root User

Once that is all setup and tested you should disable the root user:

1
$ 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:

  1. Temporarily switch to the root account: $ sudo su - That command will give you the same command shell as if you had logged into the account as root.
  2. 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

——————————————————–

That’s quite a bit of read, I know, but it really helped me to realise that all I needed to do to make gnome asking for my password (using sudo instead of su) when I click on user management was to edit the /etc/security/console.apps/system-config-users file and add UGROUPS statement with the administrator group entry, which the username I use is part of.

Tags: , , , ,

Comments are closed.