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.
Related
I think I'm misunderstanding something fundamental about file permissions in an OpenShift PHP app. How do they actually work?
I develop on OSX and push changes using SourceTree. When I log in to the app via an SFTP program (Cyberduck) the index.php file shows its permissions set to 600, yet visitors can view it OK in a browser.
This surprises me, as I thought the file would require permissions of 644 to be browsable (like an Apache webserver).
On OpenShift, it seems as though file permissions 600, 640 and 644 are all equivalent. Is this correct, or am I doing something wrong?
Related:
My OpenShift app has a cgi-bin folder containing a cgi program that should only be executed (called) from a PHP file. In other words, any PHP script should be able to call this cgi program, but a visitor attempting to browse to the cgi-bin folder directly should not.
I set both the cgi-bin folder and cgi program file permissions to 700 (so only the 'owner' has read/write/execute set, and no permissions are granted for 'group' and 'others'). However visitors can still browse to the program URL directly and execute it (e.g. www.example.com/cgi-bin/program.cgi) - as if the permissions were 777. How do I solve this?
I think you are used to a system where one user owns the files being served, and the web server runs as another user, but since the files owner (your user account that is that big long hash) is also the owner of the process that runs the web server on OpenShift, then it is using the "6" part of the permissions, so it makes sense that the other two digits that you add don't make a difference. If there is a script that you don't want web accessible, but that you want PHP to be able to execute, then you should place it outside of your web directory that contains your php files. The easiest way to do that would be to create a "php" folder in your repo, and put your files inside of it that need to be web accessible. That will change your documentRoot to that php directory, and you can put your script one level above that so users can't execute it with a web request.
In my project, I have to upload some video files to a folder which lies outside the root folder. I am using simple php function move_uploaded_file to upload the file. I have tried with the code below.
$source = $_FILES['Filedata']['tmp_name'];
$targetFile = '/usr/local/WowzaMediaServer-3.1.1/content/video.mp4'
move_uploaded_file($source,$targetFile);
But it is not working. Can we done it through move_uploaded_file. if not, suggest a better option to do this.
I have seen some similar question but nothing helps. So any help would be appreciated..
Are you sure you're not in a chroot jail?
If so, your "absolute" path name could be pointing to the wrong place-- somewhere that doesn't exist.
If so, change the path to point to somewhere within the jail.
It may be necessary to mount --bind the directory you want this to go in into some location within the jail. (Note that a symbolic link will not work for getting out of jail.)
More than likely this is a simple permissions issue and quite easy to solve.
Find the user that apache uses. To do this open up your httpd.conf file and look for something like:
User apache
Group apache
Change the ownership of the folder that you're trying to upload to.
chown -R apache.apache /usr/local/WowzaMediaServer-3.1.1/content/
Change the permissions of the folder
chmod -R 775 /usr/local/WowzaMediaServer-3.1.1/content/
And that should be that.
I'm going to assume you're using Apache for the purposes of this answer.
First off, is the file being uploaded ok? One possible reason you might have trouble is that the tmp directory isn't writable by the webserver, or readable come to that. Assuming that's ok then move_uploaded_file should work fine.
Create a folder next to your DOCUMENT_ROOT, let's call it "filestore". Make sure it's writable by www-data or whichever user runs apache. Now, you should be able to move the files into that folder. Note they will be owned by www-data:www-data typically - or whatever user and group your server is set up to run as. The reason I put the "filestore" folder next to the DOCUMENT_ROOT folder is that you can be sure the webserver can read the file path up to DOCUMENT_ROOT. Otherwise you run the risk of a folder part way up the path not being readable, and that'll stop you dead. e.g. if you have /usr/local/media as your target folder and /usr/local isn't readable (and executable) by the webserver, you're toast.
If all this works and you absolutely must have you media elsewhere, you can have the "filestore" folder anywhere so long as the whole path to it is read/executable by the webserver. Check each directory in the path.
If these uploaded files are being downloaded by other users via the web then the "filestore" folder only needs to have permissions of 700 since it's always going to be the web server's user which reads them. If other users need access, typically because other software running as a different user needs to use them then you might need permissions to be 750 to allow group members to read (and execute) the directory. You'll also need to add that other user to the www-data group.
For downloads you will need to write a simple script which dumps the file to the browser after doing some authentication checks. That way, you avoid having the media accessible just via http without having any authentication done first - which could make your service into an attractive place for illegal files (copyright violations being the least concern here).
This is a dangerous approach as it gives root privileges to the apache user, so use with caution.
Add the apache user to the list of sudoers - which will let you execute commands as root in php via system('sudo the_command'). Then move the uploaded file to a temporary location that the apache user can write do (eg. create a 'tmp' directory in the doc root). Then use system("sudo mv \"$source\" \"$destination\""); to move the temporary file to it's final location.
You can find the apache user by executing <?php echo exec('whoami'); ?>. Then add the following entry to sudoers the-apache-user ALL=(ALL) NOPASSWD: ALL. Use visudo to add the sudoer entry.
Example:
$source = $_FILES['Filedata']['tmp_name'];
$targetFile = '/usr/local/WowzaMediaServer-3.1.1/content/video.mp4'
$tempLocation = 'tmp/temp-file.mp4';
move_uploaded_file($source, $tempLocation);
system('sudo mv "' . $tempLocation . '" "' . $targetFile . '"');
Edit: Related question - How to run PHP exec() as root?
Always you face a problem with your code, look at the server log or easier turn on errors display. That said, your problem could be related to upload_tmp_dir setting. Check what a phpinfo() tells about that or look at your php.inifile.
A better solution would be to write the file somewhere where you can write (i.e. under the webroot) and then create a symlink from the media directory to be to where you wrote it.
For example:
Web Root is /var/www/html
You want it at /usr/local/WowzaMediaServer-3.1.1/content/
Create directory /var/www/html/mediaserver/content/
Make permissions on /var/www/html/mediaserver/content/ 777 (so apache can write to it)
Copy files from /usr/local/WowzaMediaServer-3.1.1/content/ to /var/www/html/mediaserver/content/
Delete /usr/local/WowzaMediaServer-3.1.1/content/ (just the "content" directory)
Create symlink from /usr/local/WowzaMediaServer-3.1.1/content/ to /var/www/html/mediaserver/content/
Then you have permissions to read/write, and the media server should too. Only issue would be if the media server is trained not to read symlinks - but you can find that out quickly enough.
I want to display image through PHP.
When I put image in /var/www/ directory then it is working fine, I am giving full path.
But when I put image in some other directory (say home) then it is not displaying.
Usually, servers have some kind of sandbox which prevent your code to access files outside of it for security reasons.
I encourage you to put all data you want your server to be able to access inside its folders (/var/www directory or subdirectories of it)
First off, you should really check your error logs as they will probably point you in the right direction.
Without more information, I'd have an educated guess that the Apache user does not have rights to the file and/or the containing directories.
You can change permissions using the chown and chmod commands in a shell.
EDIT: But don't allow access to any dir with sensitive data (e.g. your home directory) to the webserver!
I'm starting to set up the security for my web server. For this, I created a folder outside of my www folder, where I put my config.php. This file holds sensitive database infos.
I have two questions:
1) Should I rather keep it in the www folder and then move everything else down one level and make my web server point to that new web root?
2) What permissions should I set?
currently I have set the
owner to root (read-only)
group to root (read-only)
others (read-only) as well
I'm only really worried about others. Should I rather specify a user for it or create a new group altogether? Please also mention any other considerations. Thanks
EDIT: I forgot to mention, my web server distro is Ubuntu 10.10.
EDIT2: My web server is nginx
if you do move your config.php file outside of your www, you may have a openbase_dir issue, which what will not allow that script to be processed as a php file (only on certain server configs.. I think that moving your config file outside of the www folder is unnecessary as long as it is not echoing all that info out.
Keep in mind that if your server is processing php files correctly your server will not reveal the file content to the world.
so:
1) Keep it in the www folder
2) I set mine to 644
take a look at this for some more security info:
http://www.acunetix.com/websitesecurity/php-security-3.htm
Good luck,
Joe
I feel that safe mode should be off, but it's deprecated
OR
move config.php to config/ and then put this in config/.htaccess:
Deny from All
I have a problem creating an index with Zend_Search_Lucene.
Now, everything works fine on my local machine so I guess there is just an issue with file permissions on the webserver.
Here is how I'm trying to create index in controller:
$index = Zend_Search_Lucene::create('/data/users_index');
Of course the data directory has permissions set to 0777. Here is the directory listing:
public_html
public 0755
css 0755
js 0755
data 0777
Yet I'm getting this error:
Can't create directory '/data/users_index'.
Edit/Update: After further reading and seeing your structure, I'd give it a shot and try using an ABSOLUTE path rather than a relative to ensure its writing to the write location. Sorry I missed that portion earlier. It's obviously not the best practice, but it would atleast narrow down whether or not its a permission/finding issue.
So change it to something like
$index = Zend_Search_Lucene::create('/path/to/public_html/public/data/users_index');
Although, you really should put that outside of the public HTML folder. There's no reason that the public should have access to your Lucene Index Files.
For example, mine are stored here:
'../application/models/lucene/articles/index'
If you are on a Linux/Unix machine, you are going to have to CHMOD the folder or CHOWN/CHGRP so that the web server has write access. If you have access to the server, you could simply run:
chmod -R 770 /path/to/your/data/users_index
If you are not the admin of the server however, you should probably ask the server admin to make sure this is the proper permissions to be applied to this folder, every admin has his/her own quirks about how they want folder permissions setup; what group they should be in; who gets to change it; etc.
If you are on a Windows machine, you are going to have to right click on the folder and grant permissions to the IUSR_XXXXX account and give them read/write access to that folder. (Replace XXX with whatever your machines name is)
$index = Zend_Search_Lucene::create('public/data/users_index');
??