I have a ubuntu 12.04 web server. I'm trying to modify a text file called from a script located in the /var/www/* directory on the server from the website I created. Like this using php code with tick marks:
$temp=`/var/www/users/dave/scripts/script 2>&1`;
echo "<pre>$temp</pre>";

The script calls sed to parse a file:
sed 's/^........//' script1 > script2

The script runs but when the script needs to parse the text file the following errors occur:
/var/www/users/dave/scripts/script: line 22: script1: Permission denied

I've opened up the permissions on the file all the way. It occurs to me that the file won't open because the "web user" is not a "user" on the system. Is this correct and is there a way to write to a file from a website? I mean to say, "I'm not logged in how do I get write permissions"?

Oh I also tried changing the owner to www-data. Also I'm not trying to break any security rules. Just want to understand what I can and can't do.

Welcome to LQ mrdwanderson!

The web user is a registered user in your system. Which permissions did you set on the file that is to be modified or read? If you want to create a new file with the script is the directory writable for the web user?

Thank you for the welcome j-ray!

The 2nd part of your response 1st. I set the permissions to 666 rw for owner, group and others. Owner is root but also tried www-data.

The 1st part of your response 2nd. I don't think that the web user is registered on my system. The web user is really a website user. When a web site user accesses my site he is validated as a virtual user in MySQL. All pages are secure that way except for index.php in the root directory. So he logins to the site and is authenticated and can access his home page. His username is not a system username. It is a virtual username to allow access to his webpage. So what I am maybe learning is that he can't modify any files because he is not a "system" user. Stated another way. He can ssh in with his system username and modify files but if he uses the website login with virtual username he may not modify any files.

Note: Unless all website users have some group they are assigned to allow modifications. Then you assign that group to the file you want to allow modifications to.

Well thanks and hope this makes sense.

the website user is seen by your system as the apache user, depending on the distribution sth like wwwrun:www, nobody:www or similar. Probably it is not in the group "users" of the system and maybe he cannot use some system commands.

You need to check also the rights on the folder containing your file. You may need execute permission on the parent folder to write inside.
Also the file needs to owned by the webserver user as already said before.

I would also check which user is used to call sed.
I could imagine that the file must be owned by e.g wwwrun to write to it from php, but sed is maybe called as another user which has not the proper rights on this file

It's been some time, but there are two things I would check.

1/ You are trying to execute a command in your php script. See all the notes in http://php.net/manual/en/function.exec.php. If you have safe_mode on, it will not allow you to do so. You would have to modify safe_mode_exec_dir variable in php.ini.

2/ Check that your apache server can access that directory. You have to check two things, that your system will allow user your apache server is running under to access that file and directory (don't care about web users, every request is processed by your apache server and that's what your OS sees). And than you have to check your apache configuration: http://httpd.apache.org/docs/2.2/mod...html#directory, it is in /etc/apache2. It has second set of security rules for folder access on your server. Check that you can access the directory with your script.

Good luck.

I have tried everyone's suggestions, to the best of my ability, and I thank you all. But the same error messages still occur.

What I found out is that in my distribution, Ubuntu, the Apache2 web user is www-data and the owner of the physical directory /var/www is root. This must be for security purposes. I don't think there is any secure way to write to a web directory from Apache2 in my distributions way of thinking.

I was able to finally get rid of the errors and I guess the script ran, but the script could not modify or create a file in the /var/www/users/blah/scripts directory. Here is the code to get rid of errors:

shell_exec("echo 'password' | sudo -S /var/www/users/blah/scripts/script 2>&1)");

Now no errors but no file was created. I'm thinking it is possible to write to a web directory this way but ther is no secur way to accomplish this even though my directories are password protected though php scripts. Like this redirection of sorts:
if($_SESSION['username'] != basename(getcwd()))
{
$url = BASE_URL;
header("Location: $url");
exit(); // Quit the script.
}


If we have consensus I'll mark this solved or if someone can shed some light on this subject I'm up for some more work. It's the weekend!

I guess this is an important detail you didn't mention before. (Or I missed it).

If you want to write to a directory OUTSIDE your web servers root, you need to include "mod_userdir" and maybe "follow symlinks" .

It should not make a big difference which distribution you are using (except for file pathes and default options) but you need to allow apache to write or even access a directory outside /var/www/* .
Look at this :
http://httpd.apache.org/docs/2.2/mod/mod_userdir.html

the follow_symlinks directive may be needed, in case there is any linked file or folder somewhere in your structure.

Edit: If your /var/www/users directory is INSIDE your web servers root dir but OUTSIDE your websites root dir, you need to allow the access (e.g. as an alias) to this dir from the website ( pretty much like a common configuration for PhpMyAdmin or others , when it's accessible as http://mysite.xxx/phpmyadmin and your site is http://mysite.xxx and the files for phpmyadmin are somewhere in /usr/share/ or somewhere else outside the /var/www/htdocs )

If you like to post the apache.conf and maybe vhost.conf for your website and a ls from your /var/www structure it shouldn't be a big deal to make this work as it's actually a very save way to store file which should not be accessible to the public and therefore lay elsewhere

1 members found this post helpful.

Excellent heinblöd! That is what I was looking for. I wasn't very clear in my description of this. Now I understand. Thank you for hanging in there with me. I will post back my results soon. I may get some time to work on this today while the future Mrs. is baking Christmas treats.

It turns out that "mod userdir" was not my solution. That is for the ~user configuration which I am not using. I'm trying to write to web root /var/www which is owned by root. Apache web user is www-data. So I changed the owner of /var/www/* from root to www-data and now I can write. Previously I actually tried to set www-data on my directory down stream, /var/www/users/bob but that apparently won't work. I changed the whole /var/www directory owner like this:

sudo chown -R www-data:www-data /var/www

Here is a quote from someone, "The www folder is created by most distributions during the apache setup process. As the setup process is run by root, the www folder is owned by root."

So it seems you must change ownership of the directory www after installing Apache. Hm.....

I'm not knowledgeable enough to know if this is correct and, more importantly, secure. Any thoughts?

By the way you guys were correct about the file permissions. I just took that to mean the specific file. I never thought I'd need to change owner on the whole web root directory.

Well *I* guess it is fine to chown the root folder to the webserver user.
I remember some, almost flamewar like, threads about this point. ( There must be one even here one LQ somewhere).

To have /var/www/ owned by root or the www user seems to be a kind of religous question, so if it works for you, it may be fine in your setup.

Just verify that it doesn't open up any holes in maybe another website, if you have some