Simple Linux & PHP file access question..

[BizLab]

I am 90% finished with a nifty dynamic XML sitemap creation script and i am trying to write the xml files to the site root. The files will write with no issues in a 777 test folder. I am trying to have the Apache user or Group run the create-xml.php script, which will hopefully allow me to write the new file to the root folder (httpdocs) without allowing 777 access to it.

 

So, i need to run a file in /root/folder1/folder2/script.php and allow it to write to the root folder using $dom->saveXML($_SERVER['DOCUMENT_ROOT'].'/new-xml.xml') or $dom->saveXML('../../new-xml.xml');

 

any ideas on permission settings, i don't remember how to allow this to be run by the user that actually has permission to write in the root.

 

I know this is pretty basic, but my brain is kinda fried today.

OH YEA: the server is CENToS running Apache2.0 (not FastCGI)

[Wolphie]

Well to change a files owner and group the command is:

 

chown username:usergroup somefile.php

 

Is that what you're after?

[BizLab]

Thanks, but i'm looking for something that tells xml-script.php to be run as the web user (or group) that has the correct premissions to write to the root directory.

[BizLab]

UPDATE: the httpdocs directory is owned by the "user" and the permissions are as follows :

 

drwxr-x--- 2 user groupname xxxxx

 

the problem is that the file located down in the tree: domain.com/folder/folder/script.php  will not save to the httpdocs folder.

 

The "script.php" has the following:

-rw-r--r-- 1 user differentgroupname xxxxx

 

the script will be run via CRON job weekly.. Both items are owned by the same user name but have different groups. Both items are rw for the user, any ideas?

[Wolphie]

Log in as root and change the usergroup and username (if necessary to correspond to the apache files) using chmod and then trying moving it to the httpdocs folder. If you can't move it, login as the apache user (su - username) and then try moving it again.

[BizLab]

where do i find the file that tells me who is running apache? Is apache being run as apache:apache or user:apache or another variation... is that in a conf file, if so where is it generally located? /var/etc/ ?? If it is apache:apache, i can just add the webuser to the apache group (in theory, but it never actually works that way) and all should be good.

 

Its crazy that only 1 person on this forum has knowledge of this common problem. 777 is not the answer people =^P

 

It is to my understanding that if you have a user, you can add that user to a group, and give the group permission to rwx on the folder. With this, i would assume that this directory would be available for web browser uploads via php and also that the directory (the same one) would parse a file when requested from the browser.. such as an <img> tag calling an image file.

 

Neither has worked in my past attempts, which leads me to believe that the system (apache) is running php as someone other than the user i am assuming it is using. NOW, things get really hairy when i tell you that i assigned a CRON job to be run by the same user that owns the destination directory... and IT too failed.

 

What is going on here? The destination directory has drwxr-xr-x and is owned by the same user i am running the CRON job with.

[trq]

where do i find the file that tells me who is running apache?

 

grep ^User /etc/httpd/conf/httpd.conf
grep ^Group /etc/httpd/conf/httpd.conf

[BizLab]

where do i find the file that tells me who is running apache?

 

grep ^User /etc/httpd/conf/httpd.conf
grep ^Group /etc/httpd/conf/httpd.conf

 

Thanks Thorpe.

It is apache:apache.. would it be better, more safe, or indifferent if i added the webuser to the "apache" group or should i change the group to the group that already includes this user?

[BizLab]

[*]I added the webuser to the apache group and changed the destination directory's (where the files are to be uploaded) group to apache.

[*]I ran a file upload test and it failed.

[*]I then tried to give apache ownership of the file - this also failed to upload.

[*]The directory is set to a high drwxrwxr-x permission.

 

any ideas? the system is running as apache:apache

[trq]

would it be better, more safe, or indifferent if i added the webuser to the "apache" group or should i change the group to the group that already includes this user?

 

I assume by 'webuser' you mean a user on the system that has the ability to write to the http server's document root. I would add them to the Apache group.

 

[*]I added the webuser to the apache group and changed the destination directory's (where the files are to be uploaded) group to apache.

[*]I ran a file upload test and it failed.

[*]I then tried to give apache ownership of the file - this also failed to upload.

[*]The directory is set to a high drwxrwxr-x permission.

 

any ideas? the system is running as apache:apache

 

Sounds like it should be working. Can you show us the output of.....

 

tree -p ${serverroot}

 

Where ${serverroot} is the base of this entire setup.

[BizLab]

So after landing on a helpful page from a random search i have uncovered the following information. The reason people have to set file upload directories to 777 is that the server serves/uploads files as the "nobody" user by default. This "nobody" user is part of the world/other in the permission settings.

 

After checking the httpd.conf file (as per Thorpe's instructions) i found the user:group to be apache:apache - but the files on the server still seem to be served/uploaded (uploaded meaning web file uploads, such as user images) by the "nobody" user, since the upload will only work when the permissions are set to 777.

 

The strange part comes in when you consider that i have explicitly defined the user for the CRON job, and this user is also the owner of the destination (httpdocs) directory and part of the group belonging to the directory. Both the owner and group for that httpdocs directory have write permissions, but when i try to run the script that will update and save an XML file, i come up with a permission denied error as follows:

 

PHP Warning:  DOMDocument::save(../../../sitemap-cron-test.xml): failed to open stream: Permission denied in /var/www/vhosts/domain.com/httpdocs/admin/office/cron-jobs/xml-sitemap-users.php on line 123

 

This means that the file save process is still being run by the "nobody" user even though i have it set to be run by my user.

 

OK strange.. i just modified the permissions on the httpdocs for a test to 777 and the cron job is still failing - permission denied.

 

Another test: i built a "cron-test" folder (777) and tried to save the XML to it. The test script and the destination file are located in the same cron-test folder - and the result is another permission denied error, which is impossible since i have the folder set to 777... wtf??

 

PHP Warning:  DOMDocument::save(sitemap-cron-test.xml): failed to open stream: Permission denied in /var/www/vhosts/domain.com/httpdocs/admin/office/cron-test/xml-sitemap-users.php on line 125

 

I should tell you that the XML generation script works 100% on my localhost (windows/xampp/apache) and will save & update the file perfectly.

 

My goals

I need to run file upload processes by a user inside a group with write permissions

AND

Fix this cron job so that it will be run by the same user as above (currently the FTP user)

 

[BizLab]

OK guys, i found some help from the guys over at linuxforums.org (i didn't even know that existed, lol).

 

IF YOU WANT TO AVOID USING 777

[*]Set the directory owner to apache

[*]set the group to whatever group your FTP user is in

[*]You are now able to set your permissions to 750 and have a secure, fully operational image upload system

So simple, yet so devious 

 

Now if i can get this damn XML file to save to the Httdocs directory... i will try that im a minute, after i am done removing all the 777's from the site

 

[BizLab]

CRON job notes

For anyone who is running (or about to run) a CRON job, REMEMBER that all actions are run from / releated to the Server Root and not the document root. This is where my issues where coming from.

 

I needed to save the file with the full server root file path and NOT from the document root. This means that:

$dom->save($_SERVER['DOCUMENT_ROOT'].'my-schnazzy-xml-file.xml'); // will NOT work
$dom->save('/var/www/vhosts/domain.com/httpdocs/my-schnazzy-xml-file.xml'); // works perfectly

i hope this helps someone out!

 

2 thumbs up to Media Temple for helping me out once again - even though it was outside the range of support!