How do I make CentOS/RHEL prompt me for my password (and not roots) when I run a privileged command. I have found many guides that detail how to do this for the command line but I want it to work for X windows applications as well.

Or in other words: How do I make RHEL/CentOS behave like Ubuntu.

  • It sounds more like you wanted to add this to the CentOS wiki instead of posting it as a question here... – Ignacio Vazquez-Abrams Nov 24 '10 at 18:11
  • This would make a really great answer to a question... – Cypher Nov 24 '10 at 19:02
  • 1
    Also a great community wiki, which I can not set. I am sorry you couldn't answer it to gain points, but adding knowledge to serverfault was my primary goal. – ErebusBat Nov 24 '10 at 19:33
  • 1
    Wanting to add info here is fine, but you really should take the time to follow the site format. That is ask a question how to do X, and then provide an answer telling us how to do X. Then you can accept your own answer. Heck, maybe someone might even suggest some alternative answers to accomplish the same thing using a different method. – Zoredache Nov 24 '10 at 22:58
  • Yeah, why not edit your question to a question. Then post the above as an answer and accept it. No one will have a problem with that. I've done it quite a few times because after asking a question, that no one could answer, I've found the answer myself. – d-_-b Nov 25 '10 at 1:16

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

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


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:


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:

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

$ 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.
| improve this answer | |
  • Now that is one classy answer. I pursued this path myself a few months ago and got as far as the consolehelper tool. After that, all I could see was a dead end. You have presented an extremely elegant solution, especially the UGROUPS part. Thanks! – zerolagtime Nov 30 '10 at 3:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.