HOW Not TO add user to sudoers list in Debian/Ubuntu

Update (7/21/2014):
Do not do this on a production server. It is not a good practice.

You need to have root access to do that. So the first step to become root with the following command:

ken@debian:~$ su
Password:
debian:/home/ken# visudo

Now you can add a username to the list. For example:

ken ALL=(ALL) ALL

Save the file to complete the process.

Credit: Ubuntu Forum

16 thoughts on “HOW Not TO add user to sudoers list in Debian/Ubuntu”

  1. miksuh says:

    I don’t recommend you to do that, only if you REALLY have to. Line “ken ALL=(ALL) ALL” gives ken full root access. “ALL=(ALL) ALL” means that user can run any command on any host as any user, so he has root access,. If you do that ken can run all the same commands root can and he can access all the same files root can. So ken can even wipe out the whole system. Remember also that if you have this in the /etc/sudoers

    ken ALL=(ALL) ALL
    bob ALL=(ALL) ALL

    Now both ken and bob have root access. ken can access bob’s files and bob can access ken’s files. They can even write to files and remove files no matter what access rights you set. because they both have root access. So all privacy is lost.

    And imagine what will happens if you use ken or bob as a regular username for everyday tasks, then your password is leaked to wrong hands…

    Sudo was meant to be used so that you give user access to SOME of the commands which need root access. Sudo was not meant to be used as a full root replacement.

    You can give user access to specific command eg. his way:

    ken ALL = /usr/bin/apt-get

    Now ken can only use apt-get, he can’t do anything else which needs root access,

    I recommend you to read sudo and sudoers man pages:

    $ man sudo
    $ man sudoers

    Reply
  2. miksuh says:

    A small addition. If you have this in the /etc/sudoers

    ken ALL=(ALL) ALL
    bob ALL=(ALL) ALL

    Then bob can even change ken’s password and then ken can’t even login anymore.

    Reply

  4. Thanks Miksuh. You brought up a very important point. I’ve never considered this ‘lost of privacy’ case as I’ve been a sole user of my Linux box.

    Recently, I’ve successfully convinced my company to run a Linux server internally. I’ll follow your recommendation to read more about sudo/sudoers.

    Reply

  6. As a service provider this is quite a nice way of handing the customer a root-capable account, yet keeping the main root password as a fall back. It also encourages them to sudo first rather than using root daily as this is a bit dangerous.

    I realise they could actually change the root password, but keeping root access from the customer isn’t the aim.

    Thanks.

    Reply
  8. trock says:

    A good way to grant root access without having it ‘always on’ is adding the entry

    user ALL= /bin/su

    This allows you to execute the command

    $ sudo su

    and enter your password to temporarily become root. Typing ‘exit’ at the shell will return the user to their regular username and status.

    Now, mind you, this will still allow a user complete reign over the system, but hopefully will make them stop and think about what they’re doing first.

    Reply

  12. I would rather leave the default /etc/sudoers file as is and add the user you want to give all privs to sudoers group. As root you can: usermod -a -G sudo USERNAME

    Reply

    • I couldn’t agree more. I would not recommend this practice in any production servers. In fact, this was written when my Linux knowledge was at a minimum.

      Someday, I’ll re-write a better or improved way of giving privileges access to users. Thanks.

      Reply

Leave a reply to pedrito el pistolero Cancel reply