I would like to update my hosts
file and restart dnsmasq
from a web interface (php/apache2). I tried playing around with suid bits (the demonstaration). I have both apache
and dnsmasq
running on an EC2 instance.
I understand that Linux ignores the setuid bit on text scripts, but works on binary files. (Have I got something wrong?). I added exec("whoami");
to the example C program in Wikipedia. Although the effective UID of the C program is 0, whoami does not return root
:-(
I would thoroughly like to avoid
echo password | sudo service dnsmasq restart
or adding apache to the sudoers without password! Is there a way out? How does webmin do such things?
I would take another approach and configure either an incron script which runs as as root, which monitors some file for changes and responds by applying your changes to the /etc/hosts file.
With the incron approach, you set an inotify entry to watch some file for changes, and respond by running a script;
/var/www/hosts IN_CLOSE_WRITE /run/this/as/root
So apache has permissions to write to /var/www/hosts using php or whatever and the /run/this/as/root script runs as root to apply the changes to the /etc/hosts file
I tend to address this by allowing the process that runs the server, in this case the webserver, to execute the relevant command, and only that command, via passwordless sudo.
For example, here's my sudoers entry to allow a user called NAGIOS (who runs my local monitoring server) to execute a plugin that checks that RAID hardware as root:
You would have something similar, perhaps:
To address your concerns above, this doesn't allow anyone who can subvert the apache process to run
sudo bash
,sudo shutdown -h now
, or evensudo service dnsmasq stop
. It only allows exactly what's specified in the sudoers file.It's true that if the
service
command is badly written, and if someone can find a way to make runningservice dnsmasq stop
as root via sudo change the mode on thepasswd
file, or start an allow-allsshd
on port 22222, or indeed do anything nefarious, then you have a problem. But in such a case you have a problem however you run the service command as root, whether it's via sudo or any other mechanism.sudo
does its best to sanitise the environment, and the service command is a stock part of most GNU/Linuxes (and has been for some time) and therefore probably has no obvious holes.Running the
service
command via passwordlesssudo
is no less safe than any other method of running it, and probably more safe than many home-brewed or other less-well-tested ways.