Greetings, ye monks!

I'm going to write a web front-end to some sysadmin things that I do. This is to allow users to do things themselves that I'm sicking of doing by hand. I'm on linux. I want to separate the must-run-as-root code from the web code.

I'm thinking I'll have a CGI script and a seperate runs-as-root-script. The runs-as-root-script will do the actual privileged actions and the CGI will gather input from users and and pass the particulars onto the runs-as-root bit. I'm thinking the runs-as-root bit will be a constantly running service, so as to avoid suid. The cgi could talk to the run-as-root bit with unix sockets or something of that nature.

As I see it, I'll need to authenticate the users twice: first in the CGI and second in the runs-as-root bit. I want to authenticate in the CGI so I can give users feedback, avoid bothering the runs-as-root bit unnecessarily and so on. I need to authenticate in the runs-as-root bit because even if I authenticate in the CGI, I don't think there's a way the runs-as-root bit can entirely trust the cgi or that a request is coming from the cgi. The cgi handles user interface and makes it possible for the runs-as-root bit to have a very limited, strictly-defined interface.

In case I'm being unclear (my usual state) here's kindof how I envision a request going:

User -> web browser -> cgi -> runs-as-root -> system

So only the runs as root bit needs to run as root.

My first and most important question is: does this make sense? Is it a dumb idea? Am I making this too complex?.

My second question is: What's the best way to communicate between the cgi and the runs-as-root stuff? Is there any interprocess communication that guarantees input comes from a particular script? Security is my #1 priority.

I hope this question is comprehensible, and thanks for any thoughts.

--Pileofrogs