Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Consider the following line in a /etc/sudoers file:

username ALL=(ALL) ALL, !/usr/bin/passwd

as far as I know, this allows user username to use sudo, unless he not uses /usr/bin/passwd. But apparantly the user is still able to get a root shell using sudo -s/sudo -i and do whatever he likes. Have I understood this correctly? What would be a better configuration if I indeed want to disallow the user to change any password as root.

share|improve this question
up vote 3 down vote accepted

Without using additional security levels like SELinux, you cannot do this. But then it is a bad idea too, since there are really a lot of other possibilities to lock other user out if one can get (nearly full) root rights via sudo.

See http://serverfault.com/questions/36759/editing-sudoers-file-to-restrict-a-users-commands

share|improve this answer
Thanks for your reply! Would then a whitelist approach be effective, i.e. only allow him to use aptitude, or would it still be possible to get a root shell? – moooeeeep Apr 17 '12 at 13:28
A whitelist could work. But you need to know all features of the allowed programs: For example, if a user (re)installs/updates a package which want to overwrite an existing configuration file, a option is provided to run a shell with full root-rights to "resolve" this issue... I do not know how the new PackageKit, which can be configured via Policykit such that normal user can install packages, handle this case. Beside this, the user can install unsafe software and exploit it to get root access. – jofel Apr 17 '12 at 14:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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