[BusyBox 0000505]: Add support for one applet being setuid for only some users

bugs at busybox.net bugs at busybox.net
Sun Nov 26 19:42:07 UTC 2006

The following issue has been CLOSED 
Reported By:                akvadrako
Assigned To:                BusyBox
Project:                    BusyBox
Issue ID:                   505
Category:                   New Features
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     closed
Resolution:                 open
Fixed in Version:           
Date Submitted:             10-26-2005 19:47 PDT
Last Modified:              11-26-2006 11:42 PST
Summary:                    Add support for one applet being setuid for only
some users
Hello.  I have a minimal system that does allow logins.  Some of the users
should be able to run route and change the default gateway, but other
users should be able to run route and only display the current routes. 
Another example is mount.  Anyone should be able to run mount to as an
alternative to "cat /proc/mounts".

This is currently not possible with busybox's setuid support and I have
resorted to installing sudo.  I propose changing the SUID configuration
support to be more like sudo, where some users (or groups) are granted
superuser rights and others are not on the same applet.

I envision this to be an extension to the SUID section like:

joe =  (root)mount,route (httpd,ftp)kill
%wheel = (ALL)vi

This sample config would allow joe to run mount and route as root and kill
at httpd or ftp.  Members of the group wheel could run vi as any user. 
This is very close to sudo syntax, but without the host specifier.  The
user defaults to root if not given. In addition the command specification
could include arguments, like: "%wheel = killall sshd"

There is the one issue of who will joe run as if he uses kill.  Ideally
these commands would be run with the privileges of all the users specified
at once, but that isn't possible under linux.  So instead by default joe
would run mount as root, and kill as himself.  But by running busybox with
the -u option, he could be a non-default user.  Or there could be an
environmental change, say, BBRUNAS.  Or there could just be a separate
sudo applet that behaves much like it's full-fledged counterpart, but that
isn't as ideal because I find in day to day use, I always forget to type
sudo before a command.

 vodz - 02-21-06 02:40  
Hmm. For set "busybox" applet eq "sudo" applet? ;-) 

 vda - 11-26-06 11:41  
It's a featuritis.

If I will ever need to allow specific user to e.g. reconfigure routing, I
will do it via my favorite toys from runit: a service with control socket
chown'ed so that user joe is allowed to send a "sv up" command to the
service, which will then perform the requested action. Service is
typically runs under root and therefore can do whatever is needed, and at
the same time it is cofigured (run script is written) by root, so we don't
open any holes for joe. (Of course, security-concerned admin usually uses
"exec setuidgid ... cmd ..." in run script of a service).

Why is this better? Because it is attainable with only shell scripting,

Issue History 
Date Modified   Username       Field                    Change               
10-26-05 19:47  akvadrako      New Issue                                    
10-26-05 19:47  akvadrako      Status                   new => assigned     
10-26-05 19:47  akvadrako      Assigned To               => BusyBox         
02-21-06 02:40  vodz           Note Added: 0001137                          
11-26-06 11:41  vda            Note Added: 0001805                          
11-26-06 11:42  vda            Status                   assigned => closed  

More information about the busybox-cvs mailing list