Hi

I'm trying to write a PHP script where it'll create a folder/directory in something like public_html/documents/$directory.

I'm trying to use exec("mkdir documents/$directory"), but whenever i've created the directory the ownership is to "apache" and not my user account. Hence, i have problems later on creating files or even simple FTP into this folder and upload some files there. It always says permission denied.

I tried to do some workaround, by creating a sample skel directory first and do a exec("cp -a skel $directory") but it appears that the ownership is still apache.

1. I also understand that a "chown" command will probably only work at root level. Is there any workaround to this?
2. Is there any other ways where i can create directories, and also sub-directories without having its ownership to apache?

Thanks in advance!

1. I also understand that a "chown" command will probably only work at root level. Is there any workaround to this?
2. Is there any other ways where i can create directories, and also sub-directories without having its ownership to apache?

If you have root access to the server the most secure method of doing what you want is this:
When you want to create a directory inside 'documents/' you should add a row to a table in a database. This table holds all of the pending directories to be created. Periodically a cron job would run and SELECT all of the rows from the directory table and create the associated directories in 'documents/' and set the ownership accordingly. This cron job would need to be run as 'root' since you are changing permission.

There are ways to make apace be able to 'setuid' and 'setguid' but generally these are bad ideas in every case. I think a separation between the user interface and the backed for this process is an absolute must!

You could have directory permissions set so that you (and everyone else) can write to it.

If you use PHP to create this check out chmod(), mkdir() and umask().

If you have root access to the server the most secure method of doing what you want is this:
When you want to create a directory inside 'documents/' you should add a row to a table in a database. This table holds all of the pending directories to be created. Periodically a cron job would run and SELECT all of the rows from the directory table and create the associated directories in 'documents/' and set the ownership accordingly. This cron job would need to be run as 'root' since you are changing permission.

There are ways to make apace be able to 'setuid' and 'setguid' but generally these are bad ideas in every case. I think a separation between the user interface and the backed for this process is an absolute must!

Hi

Thanks for this. However, the script will ultimately be on the user's account where they are not expected to have root access though.

Any other alternatives? :(

Can you tell me more about making apache to "setuid" and "setguid"?

You could have directory permissions set so that you (and everyone else) can write to it.

If you use PHP to create this check out chmod(), mkdir() and umask().

I have chmod already. Everything works great at 0755, but the problem is it's ownership remains to be apache. When i FTP into this particular directory, i cannot do anything directly. Meaning, this directory can only be worked with by apache.

The ultimate function of this script is also to accept http uploading of files using $_FILES. Since its still work by apache, there shouldn't be problems of writing into this directory right?

But i'm afraid client may want to backup his files manually because it's a Document Management System at its simplest level. So any chance to change it to the user account's uid/gid is always the best.

You would need to chown the directory, via SSH.

chown DIRECTORY USER - will do the trick.

I have chmod already. Everything works great at 0755, but the problem is it's ownership remains to be apache. ...

You can have apache create files and folders as world writable 777, that will let both user and apache (and everyone else) handle those files.

You would need to chown the directory, via SSH.

chown DIRECTORY USER - will do the trick.

Hi, thanks alot.

But then the creation of folders is actually dynamic. I can't be chown'ing it for every directory though. :(

You can have apache create files and folders as world writable 777, that will let both user and apache (and everyone else) handle those files.

Hey.

This seems to help, maybe my testing wasn't thorough enough.

But then my script will require to check for the total diskspace consumption by the directory. If i leave the ownership to apache, will there be any implications?

Anyone can read (and write) to those files, so your script can check their size too.

Unfortunately this is a problem with most shared hosting setups - the web server runs as "nobody", or "www" or "apache" - all files created by the web server will be owned by that user and the web server will only have the permissions of that user. It's a pain in the backside when you want to store MySQL passwords in a file so that PHP can connect - if it's readable by one user's PHP script, it's readable by everyone's. I personally consider this a major design flaw in PHP's Apache module implementation.

A while ago we had trouble with some malicious users who were scanning our servers for any file they had read access to that contained words like "password" - they compromised a fair number of MySQL databases this way and because a lot of our customers used the same MySQL password as their main account password, a number of customer websites were infected with Malware.

For own control panel software (which we built ourselves), we'd already been aware of this problem and solved it by having PHP run as CGI - in other words our PHP scripts were all named .cgi rather than .php, they all had the execute bit set and all started with "#!/usr/local/bin/php". In a setup with Apache suexec, CGI scripts can be setup to run as the user that owns the vhost rather than as the web server - this way the MySQL password can be stored in a file which is only readable by a single user.

When we realised that this was a massive security problem for our users, we switched all of our customers over to a secure chroot system and now on our servers even normal PHP scripts ending in .php will run as the user that owns them without modification. Most users don't even notice this and chown all their files 777 anyway, but we've added the extra step of chrooting their PHP scripts as well (and their shell access and everything else), so it's now impossible for one user on our system to view another's files.

The only disadvantage of this approach is that a separate process is spawned for each PHP script request, so the speed advantage of having PHP run as an Apache module is lost - however we believe it's worth it and bought faster servers so that there is no noticeable performance difference for our customers' websites.

If your web host implements suexec - consider using the CGI hack that I described above to resolve your problem. You can check whether suexec is enabled by creating a file called something.cgi with the following in it:

#!/usr/local/bin/php
<?php
passthru("/usr/bin/id");

Upload the file to your server, chmod +x it and visit it in a web browser - if you see your own username rather than apache, suexec is enabled and away you go.

1. I also understand that a "chown" command will probably only work at root level. Is there any workaround to this?

yes, sudo.

2. Is there any other ways where i can create directories, and also sub-directories without having its ownership to apache?

sudo again :)

just create your dirs with "create_my_dir.sh" script which contains something like:

sudo -u desired_user mkdir desired_dir_path

Keep in mind you have to configure sudo with 'visudo' beforehand.