On Fri, May 16, 2014 at 8:26 AM, Charl Wentzel <charl.wentzel@vodamail.co.za> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Hi Guys

I recently struggled with an issue for quite a few days because of the
way the /etc/sudoers file is laid out.  I would like to make a
suggestion to change it that would hopefully save others the same hassle.

I wanted to debugging in Eclipse which required me to let Eclipse run
gdb with sudo.  However, for this to work, sudo must not ask for a
password.  So I've added the following entry in /etc/sudoers under the
appropriate comment:

  # User privilege specification
  <myuser>    ALL=(root) NOPASSWD: /usr/bin/gdb

Although the syntax is correct the entry was overridden by the 'admin'
and 'sudo' group entries just a little further down, because my user was
part of both the 'sudo' and 'admin' groups... 

  # Members of the admin group may gain root privileges
  %admin  ALL=(ALL) ALL

  # Allow members of group sudo to execute any command
  %sudo   ALL=(ALL:ALL) ALL

This resulted in my 'NOPASSWD:' flag to have no effect.  This is because
sudoers has the oddity that it uses the last matched rule, not the first!

I would like to suggest that the 'admin' and 'sudo' entries be moved
just above the comment "# User privilege specification".
This would ensure that any user/group specific added by a user will
override the 'admin' and 'sudo' entries.

If this is not appropriate, maybe simply adding a comment to the file to
just to remind people of this rule would be a great help.  However, such
a comment should be added just above/below the "# User/Group privilege
specification" comments so its easy to spot.</div></blockquote><div><br></div><div>Actually, you are supposed to create a new file in /etc/sudoers.d for custom rules. You shouldn't edit /etc/sudoers directly; this will ensure that package upgrades can happen without asking you any question about the changes you made to that file.</div><div><br></div><div>You may already know that, but note that by granting your user the right to execute gdb as root without password, you have also granted yourself the right to execute *any* command as root without password (because you can execute any command via gdb).</div>