I have seen many blog posts that say, it is enough to do

aptitude install sudo
su root
adduser USERNAME sudo

But that only protects aptitude, in other words:

  • aptitude install sendmail will ask for password, you need to be sudo to run aptitude

  • apt-get install sendmail won't ask for password, no sudo privileges needed

  • If you edit protected files, like files in etc it won't ask for password, no sudo privileges needed

  • You can run and stop services like apache, it won't ask for password, no sudo privileges needed

How to fix this? This is my sudoers file:

 This file MUST be edited with the 'visudo' command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the man page for details on how to write a sudoers file.
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:$

# Host alias specification

# User alias specification

# Cmnd alias specification

This is the output of sudo -l:

Matching Defaults entries for root on this host:
    env_reset, mail_badpass,

User root may run the following commands on this host:
    (ALL : ALL) ALL
    (ALL : ALL) ALL
  • 3
    After su root, you're logged in as the root user, so you have full access to everything. To get back to being a regular use who has to use sudo for privileged operations, logout of the shell running as root.
    – depquid
    Aug 14 '13 at 18:02
  • I am new in Linux but Debian wiki says - adduser username sudo wiki.debian.org/sudo
    – AntiCZ
    Oct 17 '14 at 20:21

You haven't added any sudo rule, so you can't use sudo for anything.

The command adduser USERNAME sudo adds the specified user to the group called sudo. A group with that name must exist; create it with addgroup sudo if it doesn't. After adding the user to the group, the user must log out and back in for the group membership to take effect.

sudo is not a special group name. It's a convention to allow users in the group called sudo to run commands as root via the sudo utility. This requires the following line in the sudoers file:

%sudo ALL = (ALL) ALL

Run visudo to edit the sudoers file, never edit it directly.

I have no idea why you believe that “that only protects aptitude”. There is nothing special about aptitude. Once you've authorized a user to run commands as root, that user can run sudo aptitude … or sudo apt-get … or sudo service …, or sudoedit to edit files that require root permission to edit. Being in the sudoers file doesn't directly change the privileges of your user, what it does is that it allows you to run sudo to run commands as root. Commands run as root only when you run them through sudo. Some programs may do that automatically, especially GUI programs where the user interface runs without special privileges and only the backend runs as root, but commands executed as root are always executed by sudo.

  • He has run sudo -l as root. Even if there are useful definitions for users they would not have been shown. Thus your guess "You haven't added any sudo rule" may be wrong. Mar 7 '14 at 23:21
  • @HaukeLaging I don't understand your comment. “You haven't added any sudo rule” isn't a guess: the sudoers file is in the question. Mar 7 '14 at 23:57
  • I was close to getting depressed, realizing that I was too focussed on the sudo -l output but luckily... It seems that the question content cannot be the whole file because it is not consistent with the output. At least my sudo version does not claim "User root may run the following commands" with a sudoers without any command definition (like the one in the question). Mar 8 '14 at 0:06
  • @HaukeLaging You're right, I checked with wheezy and indeed sudo -l just says “User root is not allowed to run sudo on darkstar.”. And the sudo group is in the sudoers file by default on wheezy. The requisite entries may have been moved into a file under /etc/sudoers.d. In any case, whatever the sudoers file contains, it wouldn't do what Fischer assumes. Mar 8 '14 at 0:18

What may have happened is: sudo is caching your password. So, after you've correctly completed the implementation of sudo on your system, you have to enter the password for the first command, and after that it's cached for some time. If that happens and you run the sequence

sudo aptitude install sendmail
sudo apt-get install sendmail

Then you'll have to provide a password on the first command, but not on the second (at least while you are still within the timeout). This may feel like it's protecting only the first command, but not the second. Without further information (complete shell transcripts), there's no way to tell...

  • Yes. The one doesn't exclude the other. The correct answer does nicely explain how to set up sudo correctly, and in that sense, it answers the question. It does not explain why, in the words of the question, "that only protects aptitude". Gilles writes himself: "I have no idea why you believe that “that only protects aptitude”". As I said, to really understand that phenomenon, more information is necessary. I think a downvote is a bit harsh given that my answer is factually correct, addresses the original question and fills a gap in the existing answer.
    – Josef
    Mar 7 '14 at 22:57
  • Good idea, this may be the source of Fischer's confusion. Mar 8 '14 at 0:18

If you follow the above answer, you are going in the right way. At least in my Debian Jessie, i made a soft link to /usr/bin of the command in the path /sbin. For example: /sbin/ifup, i put a soft link (ln -s) to /usr/bin of it and i can use it.

Another important thing is to put NOPASSWD like this:

User_Alias NET = goviedo
Cmnd_Alias ETH = /sbin/ifup

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.