I've the need to run one Perl cgi as root. I already understand most of the security concerns of doing this but let me explain first.
The Perl cgi could run as the web server but would require sudo access to run some commands. This is what I've done first but this doesn't only allow that cgi to run these commands but the whole user running the web server. Also, instead of running commands with sudo, I would prefer to use native library that are way faster than running external commands. However, these native library requires root access for some of the operations.
So what I had in mind was to run this one single cgi as root (haven't really found how yet, this my main issue right now). The first thing I would do in the Perl cgi would be to change the effective uid $> / gid $) to a non-privileged user and only change it back to root when I need to call one of the native library requiring root access, then change it back to the non-privileged users.
So far, do you have any comments on this idea?
Back to the main question: how can I allow that cgi to run as root? I've taken a look at suexec but it doesn't seem to allow root Can't use setuid on a Perl script looking for some help/ideas here
Best regards,
Yannick Bergeron
I would likely try to investigate one of two options, both fairly similar.
The first is a job engine. Your CGI would do nothing but post a request to the engine queue. The client would come back and poll for results. Works well if you already have such an asynchronous queue set up. The engine itself would run as root to be able to run requests. Requests would not, of course, include actual commands to run - security is still a significant requirement.
The second option is a daemon. It would listen on an internal port (only on the localhost adapter, perhaps), and receive the requests. It would then return the results on the connection. If your CGI and daemon are both in perl, you could even just serialise via Storable, though I'd generally prefer JSON - it's not always bigger than Storable, and it's not generally a lot bigger than Storable. But it's fast, secure, and amenable to both reasonable tracing without modification and may also be good for sending back to the client without modification, depending on your needs.
Again, security - you don't send commands to run or SQL phrases, you send requests and parameters. But that's the same as your CGI code.
Both of these options require an extra process (or more). But they also avoid a lot of the overhead - you don't need to reinitialise the C runtime library each time, you don't need to recompile perl code each time, etc., and they take care of privileges outside your CGI code.