Is there a way to allow su only for specified users (like using visudo for sudo).

The reason for this is I'd like to keep a simple (weak) password for my root account and have accounts that can su/sudo only be able to login to the machine using a pub/private key.

Then, all other accounts would not be able to su as root or as an account that can su.


9 Answers 9


Yep, the 'wheel' group trick is also available on linux: you just need to configure pam for it and then, only wheel members can run su.

On Debian, you have to uncomment the wheel line of /etc/pam.d/su

This is definitely the first thing to do on any server, or else, any webserver/ hacked can lead to a root hack.

  • On older or non-PAM systems, instead edit /etc/login.defs and set SU_WHEEL_ONLY to yes. Sep 28, 2009 at 13:28

A weak password for root is foolish, regardless of the controls on 'su'. Even if user 'root' can only login at a console in a restricted machine room, I would not allow user 'root' to have a weak password.

I'd suggest disabling 'su' altogether and using 'sudo' for everything. By disabling, I mean any of:

  • Exploiting any system-specific means of restricting access to 'su' (such as the group 'wheel' trick for BSD, or the Linux equivalent). Note that there is no formal standard for this; POSIX does not mandate the presence of 'su', for example.
  • Remove it (rm -f /bin/su).
  • Remove its execute permission bits (chmod o-x /bin/su or chmod go-x /bin/su).
  • Remove its setuid permission bit (chmod u-s /bin/su).

The residual problem with disabling 'su' by removing it or removing permission bits is that some system scripts may depend on su being present. There isn't a particularly clean solution for that - but they are generally few and far between because 'su' prompts for a password and prompting isn't liked in scripted environments. The other time 'su' is used is when 'root' runs the command to become another user; this is supported by removing the setuid bit (user root can run it, but no-one else can do so usefully). You might reinforce that by removing public and possibly group execute permission too (chmod u-s,go-rwx /bin/su).

If you are not using one of the system-specific means, be very careful; test before putting this into production.


If you system uses PAM then you can disable su properly by putting something similar in /etc/pam.d/su:

# This allows root to su without passwords (normal operation)
auth sufficient pam_rootok.so

# Disable all other uses of su
auth requisite  pam_deny.so

# [rest of file]

On FreeBSD, only users of the group 'wheel' are allowed to su.

Which OS are you using?


You can edit the /etc/sudoers file to control who can use sudo and what they can do. If you allow programs that can spawn a shell (shell escapes) then a user can do anything.

See the man page for sudoers for more details.

  • The question was limiting who can run su, not who can do what with sudo. su is a command that is there on it's own, and out of the box any user can run it to try become root, without the need to use sudo in any way.
    – Bart B
    Sep 28, 2009 at 10:01

First of all, su and sudo is a completely different commands.

sudo allows you to execute a single command as a root (or different user if specified), where it's behavior it's is controlled by /etc/sudoers.

su will run a shell as a root (or different user if specified).

What I can recommend you - leave a strong root password and place all the users that needs root privilegies in /etc/sudoers (Check this article).

The other, less recommended idea, is to use su wrapper script.

  • yes I know they are different; since sudo has this option to specify which users can sudo, why not su?
    – verhogen
    Sep 28, 2009 at 7:54
  • also, if I leave a strong root password, a user can still su to a sudoer and do things from there.
    – verhogen
    Sep 28, 2009 at 7:54
  • I'm trying to tell that using sudo your sudoers will not know your root password. Sep 28, 2009 at 8:02
  • I know. The issue is if a non-sudoer su's to a sudoer (by knowing the password of a sudo-er (not necessarily root)).
    – verhogen
    Sep 28, 2009 at 8:15
  • Again... DON'T tell your root password to anybody and place in /etc/sudoers whoever you need (configure sudo for not asking the root password for those people). This way you will give root privilegies to appropriate people and nothing to others. Sep 28, 2009 at 9:33

Yes. chmod su to 700, and put everyone who you want to use it in the root group, in /etc/group. Using sudo is however, almost certainly a better idea.

  • that's a solution; but can't people upload they're own su and use that instead? yes using sudo is the idea, but what if a non-sudoer su's to a sudoer.. then he can do anything.
    – verhogen
    Sep 28, 2009 at 9:38
  • No, they can't (unless they have root, in which case all bets are off anyway, as they could just upload an suid bash). su has to be suid to work.
    – Cian
    Sep 28, 2009 at 10:16

Depending on what auth your machine use you can edit /etc/pam.d/su or if your system don't use pam, you can create a file /etc/suauth with the rules for the users or groups that have access to su as root.


I just want to reiterate what others where trying to say which I'm not quite sure you've grasped. If you disable access to the su command for all users, no user, even if they have their own copy of su will be able to switch to another user account. This is because the su command needs to have the root suid bit set in order to allow the user trying to run the command to change their UID. It would be much better to have a very strong root password, disable the su command for all users, and give those users you want to have root privileges sudo access.

It sounds like you're afraid of the people that have sudo access will share their password with other users , giving them root access as well, which is really a problem you're not going to be able to solve. The privileged user could always just let them sit at their computer if you have public/private keys setup as well. It comes down to you can only give a user admin privileges when you trust that user.

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.