Conflicting design issue for hide-admin-tools-to-users

Anand Kumria wildfire at
Tue Jan 3 16:04:34 GMT 2006

On Fri, 25 Nov 2005 11:59:08 +0100, Martin Pitt wrote:

> Hi Carlos!
> Carlos Ribeiro [2005-11-25  8:22 -0200]:
>> My first guess was 'why not patch sudo for some extra option', but you're
>> right, it would mess with someone's else code. 
> I already did - I added the -t option to test whether a command can be
> executed without actually doing it.

Why not just use 'sudo -l' which lists the set of commands which can be
executed by a user.  While that does log the fact that sudo (with
command=list) was run, that isn't a "failure"

>> But - is there any reason why a simple tool to parse /etc/sudoers
>> would not work? It would replicate some of the work that sudo
>> already does, but I assume that the format of the file is pretty
>> stable.
> Yes, /etc/sudoers can only be read as root. So you need a suid root
> program anyway, and sudo already has all the necessary parsing stuff
> and is proven code. The -t patch is trivial and safe.

Well, the output from 'sudo -l' is reasonably easy to parse and the worst
case scenario if your parser is incorrect is that a menu option that a
user is not able to execute will appear.

sudo will, at the end of the day, enforce the permissions assigned to the


More information about the ubuntu-devel mailing list