Command execution though php / perl scripts as a privileged user in linux

Question

Background . I am writing a script for a company that will allow users to create FTP accounts through a web interface. In the background, the script should run a bunch of commands:

• Add the user to the system (useradd)
• Open and edit various files
• send message to user via sendmail

and a few more things ...

I'm basically looking for the safest way to do this. I heard about the setuid method, the sudo method, and of course httpd is running as a privileged user. They will be checked for validity of the entered data before any commands are executed (i.e. only alphanumeric characters in user names)

What is the method used by popular scripts (e.g. webmin) as it should be fairly safe?

Answer 1

I would set up a queue that a web related script can write.

Then I will have some privileged process read from this queue and take the appropriate action. You can run the script command line with a cron job, or write a little daemon in PHP that checks the queue and does the work more often than cron allows.

Thus, the only code that can work with privileges is your little working script, and you do not need to provide any way for a web-bound script to get the necessary but dangerous privileges.

Answer 2

Create a script that takes a command line parameter, validates it, and runs the useradd command. Add your httpd user to the sudoers file with the NOLOGIN, JUST directive for this single process.

This way, you don’t have to worry about writing a daemon that will always run with root privileges, and your script will also return immediately. If you just used the root setuid script, other users from the same system could run your script (if you did not verify your real user ID).

Answer 3

To begin with, running httpd as root is a very bad idea.

a safe way to do this is to completely divide privileges between the web server user interface and the effector - one obvious way to do this is to start the server with root privileges, accepting only local connections that the user interface sends its requests (an easy way to do this via inetd / xinetd ), which means you don’t have to worry about all the complications associated with setting up the daemon process).

You will also need some kind of trust mechanism between the user interface and the effector - a common secret will be sufficient - so that other programs in the system cannot invoke the effector. Using a trust system based on outsourcing or asymmetric request-based encryption means you no longer need to worry about local communication restrictions.

Finally, you need a well-defined protocol through which the user interface and the effector interact.

This is much more complicated than using sudo, but more secure (for example, sudo allows users to execute certain files as another uid - you hope the file contains the correct program).

Setuid has the same drawbacks as sudo with added complication, which (in most cases), if it starts another program, then it will do it as the original uid.

NTN

FROM.