I'm a student at the university of KULeuven and I'm currently investigating the options to perform root operations in web servers which don't run as root.I already found a lot of solutions (running a daemon etc). For security reasons you don't want to run your webserver as root, but as a user like www-nginx with limited permissions. However, ISPconfig 3 must perform certain root actions to reload the server config at certain stages. But I was curious: What does ISPconfig 3 uses for this matter? Responses can be very technically, I even would happy if they would go in detail.
Each server runs a cronjob as root, which can perform any actions needed. Code: # crontab -l * * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done * * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
Thanks for pointing me in the right direction!If In the file "/usr/local/ispconfig/server/server.sh", I see the following line: Code: /usr/bin/php -q /usr/local/ispconfig/server/server.php So it basically runs a PHP script as root at first sight. When I look at this PHP file, I see some root commands executed passed via a shell: Code: exec($command, $tmp_output, $retval); and: Code: exec('cd '.escapeshellarg($web_path).' && sudo -u '.escapeshellarg($web_user).' find . -user '.escapeshellarg($http_server_user).' -print 2> /dev/null | zip -b /tmp --exclude=backup\*'.$backup_excludes.' --update --symlinks '.escapeshellarg($web_backup_dir.'/'.$web_backup_file).' -@', $tmp_output, $retval);
ISPConfig runs several actions as root but this is not related to the web-server. The crontab is the crontab for the user root on a server.
ISPConfig consists of two completely separated parts. The web interface (which runs as user ispconfig and is accessible from outside) and the server part, which gets executed by cron as root user. Both parts communicate trough a mysql database with each other. That a script is written in the PHP scripting language does not mean that it is a website secript, you can write all kind of applications in PHP and you can use it for shell scripting as well like we do. So the solution that ispconfig uses is similar to running a daemon as root user plus a separated web interface that runs under a non priveliged user, just that we let cron execute the "root user" code once a minute instead of using a daemon that runs permanently. ISPConfig uses the sys_datalog in the MySQL database as job queue which then gets processed as batch by the server.php script.
Thanks for talking this trough in detail! I'm writing a paper for my thesis, do you guys mind if I reference ISPconfig? A lot of tutorials online mention to edit the sudo config file to allow a php script in the webfolder (which is accesable by the web and thus a security problem), I would like to mention ISPconfig as a good example on how you handle this problem in a secure way.The method you describe is indeed very similar to a daemon + ISPconfig used a security best practice to seperate the user web interface and the root operations in the PHP script. If you rather not got mentioned in my paper, I can understand that completely!
Sure, feel free to mention ISPConfig in your thesis. Using sudo from within a web server script is a security nightmare indeed and that's why we have gone the other route You can see the code separation also in the ISPConfig directory structure: Base directory is /usr/local/ispconfig/, there you can find the directories: interface (which contains the "web" interface that is accessible from the browser), these files are owned by non priveliged ispconfig user. server (which contains the server part of ISPConfig). The files are owned by root and can not be accessed from User "ispconfig" that runs the interface. The server and interface are completely independent from each other and don't share any files. The security directory contains some security settings that we felt should not be editable from interface and should also not be in the database. But the interface must be able to read them, so we needed that third directory which is owned by root but provides read only access to the ispconfig user (unlike the server directory that can't be accessed by the user ispconfig at all).
