0

I'm building a NAS control application with PHP, that can be only accessed from the local network.

I'll start it off with that PHP-FPM does not allow to launch it's pools with user root, and I have not found a way to force it.

Yes, yes, running PHP as root is not secure (and building an OS configuration app also), but I have no other idea how could I edit Arch Linux's /etc/rc.conf directly from PHP with file_put_contents() and after execute rc.d restart network.

I have set open_basedir = / in php.ini.

I have read this and, therefore, I set up a sudoer, launch PHP-FPM pool with the respective user and group.

My sudoer is a system user, added with:

useradd -r -s /bin/bash -g wheel -d /srv/http/ systemphp

In sudoer configuration I have added the entry:

systemphp stone=NOPASSWD: ALL

stone is the actual hostname of the system.

The problem with this is that I'd have to sudo <everything>, but I do not want to base everything on shell_exec() / exec().

Since, any option here is an option, I still tried:

var_dump(shell_exec('sudo fdisk -l'));

That returned null. Where in PuTTY, su systemphp, sudo fdisk -l returned the actual list.

Without shell_exec(), the following code results in fopen(/etc/rc.conf): failed to open stream: Permission denied:

$handle = fopen('/etc/rc.conf', 'r+');

if ( $handle )
{
    while( ($buffer = fgets($handle)) !== false)
    {
        echo $buffer;
    }

    if ( !feof($handle) )
    {
    echo 'Error: fgets() unexpectedly failed' . PHP_EOF;
}

    fclose($handle);
}

How would I set such an environment up or at least reflect it?

tomsseisums
  • 205
  • 1
  • 2
  • 10

2 Answers2

2

Please don't build web interfaces that edit critical configuration files.

Instead, you can build a web app that let users modify a copy or a template of this configuration file. Then an agent or a schedule script can actually modify this configuration file.

This is the way most scm work. Have a look at puppet or bcfg2 to see how it was done in other languages.

  • They won't be able to edit the file, only specific parts of it, abstracted into single line input fields, that on post will be stripped, sanitized and cleaned for each entry specifically. Plus, that will be enhanced with server-side validation, and since the OS configuration changes will be minimal, I do not see a way to cause harm to the system. – tomsseisums Aug 22 '12 at 10:18
  • The point is, if you would be able to run FPM as root, any flaw in your app or FPM might compromise the whole system - even if you intend the user only to do specific things. Once root.. Another idea: You could build a minimal server application running as root (not via php-fpm but as a regular daemon) with a simple TCP/IP or unix socket API. Your app can talk to the server and execute defined commands / send defined modifications to files. – ukautz Aug 22 '12 at 22:18
  • I did found my workaround - replacing nginx + fpm with Apache and mod_php. Custom compiled Apache that allows to be launched with root permission nails everything, but, anyways, I'm following another path. – tomsseisums Aug 23 '12 at 06:36
2

While I agree strongly that this is a bad idea and that you should, in fact, edit a temporary copy and have something else copy it over, if you're determined to edit rc.conf directly, create a group, make systemphp a member of it, change the group ownership of rc.conf to that group and give rc.conf group write permissions.

This is at least a lot less of an opening for potential fuckups than giving the user NOPASSWD: all permissions via sudoers.

Also, this is still a terrible idea. You may not see a way to cause harm to the system, but it's going to be awfully difficult to ensure that. I'd go as far as to say you can't. rc.conf is a bash script, it's sourced, good luck taking care of potential edge cases.

As an aside, I can't even think of anything in rc.conf that would be useful to change like this, especially as it's a very minimal file on up-to-date systems -- basically anything would probably be more appropriately changed elsewhere, or changed in a different file and telling rc.conf to source that file, if it did actually need to be present there.

jdd
  • 266
  • 1
  • 3
  • Well, on Arch Linux, `rc.conf` contains startup daemon list and network settings. – tomsseisums Aug 23 '12 at 06:34
  • Yes, I know, I've been running Arch for a few years now. Also, network settings can be set elsewhere (and in a variety of ways), and both network settings and `DAEMONS` are being phased out of `rc.conf` into separate files. Settings in `rc.conf` currently still work. – jdd Aug 23 '12 at 07:16