Using a standard LAMP server with full control, I need to upload an image from DomianA using a PHP script to a directory on DomainB. The server has suPHP and mod_security in place.
Currently using an absolute path to DomainB I am getting the error:
Warning: move_uploaded_file() [function.move-uploaded-file]: open_basedir restriction in effect.
I tried to chown the upload directory on DomainB to the user of DomainA (where the script is being run). With no luck.
After researching I have found two potential solutions, and want to see if there are any better methods. And maybe some code to get me going in the right direction.
Symlink - so basically have a dir (below the domain level I guess?) then have each domain have a symbolic link to that location.
Modify my httpd.conf - not sure what to do, but I don't want to open any potential security holes by doing this.
If domain B only needs to serve up files from that directory and not modify them, then put the directory somewhere in domain A's tree, with proper permissions to allow the uploads.
You can then configure domain B to access that directory via an alias:
Alias /path/to/the/files/in/domain/A /dom_a_dir
Then you can access the files directly via
http://dom.b.com/dom_a_dir
Related
In my code for uploading pdf documents to my web-server, I have used move_uploaded_file.
move_uploaded_file($tmp_source, $destin)
However, this command does not work unless I give 777 access to the uploads folder. I tried making it 775, but it wouldn't work.
I get the following error message
failed to open stream: Permission denied in /srv/http/host1/public_html/internal/upload.php on line 82
By putting the uploads folder above public_html, I can prevent people from accessing them via a browser, but how do I prevent local users from accessing this folder through ssh?
Some answers related to this question had suggested using
ps aux | grep apache
to find out the user to who the upload folder should be given appropriate permissions 0755. This information did not work for me.
However, the correct information was available in phpinfo() under the apache2handler header. It was http.
Among other things, I have restricted file types to pdf, set .htaccess to restrict cgi and also kept the uploads folder outside public_html to prevent access through browser.
I am not aware of further security concerns.
I just made a mistake in a PHP application I'm developing with WAMP Server.
My WAMP / WWW folder is inside my D:\ disk, where I also have my personal data. My app, due to a fail in generating a dynamic path, deleted all my music, my photos and other personal files I had.
I mean... WHAT? How was it possible? I will need a recovery tool to recover that data.
How can keep the PHP from touching anything outside it's folder in www so it does not happen again? It's a disaster.
Limit the files that can be accessed by PHP to the specified directory-tree, including the file itself.
http://php.net/manual/en/ini.core.php#ini.open-basedir
Use open_basedir to restrict file operations to within specific directories, like this (in the website's VirtualHost file)...
php_admin_value open_basedir "C:/WampDeveloper/Temp/;C:/WampDeveloper/Websites/www.example.com/webroot/"
Though if you are deleteing via the command line or bat file (e.g., you are not using PHP file functions directly), the only way to fix this is to set Apache to run under a custom account that only has permissions set on WAMP's folder.
I have a project where Red5 is recording videos. I need PHP to be able to access the videos and move them so they can be accessed by HTML.
How can I do this?
I found this post: Accessing files outside the document root with Apache
But it involves updating some file that was never specified. And I'm not sure it is a viable solution in this case anyway.
lee
PHP by default can already access files outside the web root, unless restricted with an open_basedir directive (or safe mode, but hope you're not in that cage).
It's normally a good practice to insert within a VirtualHost configuration an open_basedir restriction. You can specify multiple directories separated by : on Linux and ; on windows.
php_admin_value open_basedir /var/www/s/stage:/usr/share/php:/your/dir
To access those files either use an absolute path or a path relative to the position of the PHP file called. (So you'll have to ../ to reach levels above).
Also be sure that directories in which you want to write to are assigned to the webserver user and have write permission.
I have a PHP web application running on IIS, which allows a user to upload a file from a simple html form. The uploaded file is then moved to a folder on another server. This is working correctly on Apache, but fails on IIS with the error:
function['move_uploaded_file']failed to open stream: Permission denied
in...
I've checked all the permissions on the directories. If I run a simple PHP script through the command line to copy a file from the server into the folder on the other server it works correctly, so I suspect the problem is with IIS.
if (move_uploaded_file($_FILES ["file"] ["tmp_name"], "\\\\000.00.0.00\\tia\\web\\upload\\" .$_FILES["file"]["name"])) {
This has been covered already here. Quoting the reason here:
You have mapped target directory to a share such as \server2\files. These mappings are only available to the current users (eg, the admin account), not to the IUSR account that your php is probably running as (assuming IIS). Solution, don't use mappings, instead use the full 'unc' path name, ie '\server\share\folder\file.ext', also remember that the IUSR account will need access to these shares/folders/files
From what I can see in your comment, you are using a \\ prefixed network share as the target for your move_uploaded_file() operation.
I'll bet a beer that PHP isn't allowed to access that share. Remember, PHP runs with IIS's permissions!
Try saving to a local, globally writable path first. If that works, you know you have to fix the share's permissions.
See an example here: http://mattpotts.com/portal/
I put an includeme.htm in each directory on the required path to find the point of failure. It works fine on my local machine (windows) with the same directory structure but fails on my remote (linux) server.
Directory structure:
+-firefli/ drwx--x--x
+-private_html/ drwx------
+-foo/ drwxr-xr-x
+-bar/ drwxr-xr-x
+-portal/ drwxr-wr-w
+-public_html/ drwxr-wr-w
+-foo/ drwxr-wr-w
+-portal/ drwxr-wr-w
The permissions confirm that it's the private_html directory causing the trouble. Hopefully you can see the purpose of the directory structure, I don't know if it's a common way of doing things but it works for me. Well, until now.
I've gone a very long way around asking it but my question is simply this: is there anything wrong with setting private_html to be drwxr-xr-x? Given that I do not want it to be accessible via the web. But the permissions shouldn't do that should they? Because it's apache making the public_html directory accessible via http.
You shouldn't need to block out web users with folder/file permissions on private_html, as it's outside the web root. As you say, web users can only get to stuff in public_html
For future debugging speed, if you have a relative web path you can convert it to a real path using realpath:
$path = realpath('../../private_html');
// $path is now /public_html/foo/private.html or whatever
Well, if you have set up your DocumentRoot correctly to point to public_html, it won't be accessible from the web, no matter what permissions you put on it.
The Private HTMl is not accessible from the web without you putting in a .htaccess file that would redirect it. If you don't know what that means/how to do that, you are safe.
You should be fine setting these permissions to whatever your script needs.
what are the user:group for private_html? The web server needs to be either a member of the group or the owner of the file. In order to read the directory contents the dirctory needs to have the execute permission for the webserver to open it. Essentially they should have the same user:group as public_html. You just want to disallow the write permission. tot he webserver. If you have set your document root to public_html private_html is not accessible via the web no matter what the permissions. Also, i always use realpath on the path arguments to and file operation.