I was reading some posts about how to include files outside php root (Apache root). I guess only reading a file is a easier task, may be done with the same solution. But I do not intent to put php or any other script file outside my document root (right now is /Library/WebServer/Documents/), I wish to keep only one root with usual configurations.
But any file outside root is not "visible", it's like my all HD were made just by the root. Php did not return permissions error, it returns file don't exists (or is not a directory error). Is a good security practice, but make my scripts blind! I have a small Intranet an one task I wish to do is to read Safari's favorites file (Bookmarks.plist), also I wish to make a photo viewer, etc.
So I just want to read those files. Is there some hack for this?
EDIT: I was using file_get_contents. Following suggestions, I tried include that stops in permissions issues (probably owner issue). I did a test with a simple file in a Volume (an external HD) and it included just fine. However, I'm thinking in how to deal with data, you know, I was expecting to read the XML to work on it...
EDIT 2: file_get_contents is working with a file in an external HD, so the problem seams to be about permissions/owner file. The info window shows the same users for both files: me, staff and everyone with at least read permission. Maybe there is some "hidden" user... any hacker around?
Related
I have a REALLY strange thing happening! When I view a file (within the "Program Files (x86)" folder tree) in my file manager it has one content, but when I retrieve it through PHP CLI script using file_get_contents() it has different content (with some additional lines I added through the script earlier) - except if I run the CLI script in a prompt with admin rights, then I see the same content. How on earth is it possible that the same file can have different content based on the permissions of the user accessing the file? Is that really possible, and if so where can I find more information on how it works? I've never heard of such a thing in my 25+ years of computing and programming experience...
I have quatro-checked that the path is the same and checked in all kinds of ways that there isn't something else playing a trick on me - but I just can't find any possible explanations!
I'm running Windows 10.
32-bit applications that do not have a requestedExecutionLevel node in their manifest are assumed to be UAC-unaware and if they try to write to a privileged location in the file system or registry (when the process is not elevated) the write operation is virtualized. Virtualized files are stored in %LocalAppData%\VirtualStore.
Manually delete the file in the virtual store and then edit the ACL/security of the file if you need to write to it from your script as a standard user...
So I created a couple of directories and files with FTP, thus the owner is the username I use to login to the server. Now I'd like to allow users of the website to upload images to those directories. Unfortunately for the website to store images, it should be owned by Apache. How can I fix this? I've been reading around on this but can't directly find an answer.
I don't have SSH, so I guess all command-line-things are not applicable for me.
Edit
I tried to then make the folders again using apache, but now ofcourse I can't write any files using ftp into those directories.
Provided that at least the one directory is writeable by the apache user (lets call this directory 'writeabledir', it may be your root dir '/'), you must delete the folders you created via ftp and create a php script to create the directories you need.
If for example you want a directory called users and inside it another directory called upload
Create file makedirs.php on your server.
<?php
$oldumask = umask(0);
mkdir("writeabledir/users/upload",0777,true); // or even 01777 so you get the sticky bit set
umask($oldumask);
?>
Now run your makedirs.php once, by calling your.serv.er/makedirs.php on your browser
EDIT:
If you don't want to delete and recreate your directories,you could always try to change file permissions from ftp.
For exampe with FileZilla, just right click on the desired folder and set permissions to 777. If your ftp user does not have permission to do this, then there is no other way, except from asking an administrator to do this for you.
EDIT2:
Added umask to ensure that folders created by apache are writeable by everyone. (taken from http://us3.php.net/manual/en/function.mkdir.php#1207 )
Friend looks I work in php, some versions change the way of solution, however the most common is already that you want to store it would be necessary to create a database and import it to esu code that also serves to some images you want to come place, plus the wisest thing to do and you create a database with the fields necessary for its realization, import, put in a file directory of your schedule, you also advise using aptana Studio 3 greatly facilitates the creation of codes among many things and low xampp it already comes with apache integrated in one place will help you a lot any questions on installation just look at youtube he will describe
I am writing a file upload using Zend_Form_Element_File(). I created a directory called users in the public directory. When I load the file, I got an error saying page is not found. I check the directory and saw that the permission is drwxr-xr-x. So I change the permission to drwxrw-rw- and load the page again. The page loads properly. But when I upload a file, it produces an error again. So I finally change the permission to drwxrwxrwx and everything runs properly.
My question is that am I doing the usual way that others are doing? I found it strange to make a directory executable.
Can someone explain whether I'm doing it correct? I am just learning Zend framework.
Directories must be executable if a program should be able to "enter" it. Entering a directory basically means accessing any file/directory below that directory.
Having "read" access to a folder allows you to list its contents - what "write" access does is pretty obvious.
However, for security reasons you should check if drwxrwx--- (770) is not sufficient; often your user and the webserver share a common group. If that's the case, there's no need to give any access to "world".
It would be even better to run your scripts as the same user as you - by using fastcgi that wouldn't be too hard, but if you are on shared hosting you usually do not have the necessary access to do this.
Typically when you set permissions on the directory it is so they cascade down to the files within via extended ACLS in the majority of cases. The issue that I see immediately is that you have granted world access which is a bad idea. The only user that needs permissions to the directory (700 at max) is going to be your web server. So I would revert security to be 700 asap.
In a module I'm creating I have some sensitive information I need to store securely: A remote database host, username, and password.
It seems that the only storage available is in the Drupal database, which worries me since this means if Drupal is compromised so is this other database. The settings.php file in sites/all/default was my second option, but I'm having trouble writing to it. Various chmod commands in FTP and SSH to 777 and 666 won't open the file to writing. I'm also not sure if the variables I set there are available anywhere else.
Are there any other ways to store this information securely?
You're on the right track using settings.php. You can use the $conf variable in settings.php to set variables that you can access in modules using variable_get.
Hmmm... this seems like something you shouldn't do in general. Write an API that sits at the remote database that you can access.
If however you insist on direct database access. Hard code the host, username and password in a file, put the file outside your document root and include it from there. For example, if your document root (i.e. where Drupal's index.php file is) was /www/htdocs, put a file containing the info at something like /www/secure and include it where you need it. Then if php stops working for some reason, the file isn't in a readable location to the outside world but PHP can include it within the site as necessary.
Sure somebody might see that you were including the file but they wouldn't be able to see the file itself unless they hacked your server (rather than just Drupal) and in that situation, your pretty much screwed anyway.
Using a config file is ideal for this type of information. However doing a chmod 777 or 666 is a really bad idea. The problem is that both of these settings allow the file GLOBALLY read/write. So if you are on a shared host, then its possible for another user on the system to access your file. On install trying using php's chmod() function to do a chmod 500 on the file. (500 should work in most cases, the most important part is that the last number is zero).
I have a script that allows only authorised users to upload files to a certain folder.
However I do not know how to prevent people from downloading freely without login.
I need the solution in php.
I have googled around but nothing straight forward as yet.
Currently in my document root I have a folder called admin and a subfolder called uploads inside the admin. So only admin role can upload. Both editor and admin can download. What should I do in this case?
Please advise.
Put the files somewhere outside the public webroot directory, or configure your server to not serve the files. As long as your server will happily serve everything with a valid URL, there's nothing you can do with PHP to prevent that.
If your files are in the /public_html/ folder, take them out of that folder and place them in e.g. /secret_files/, so your directory structure looks something like this:
public_html/
index.html
admin/
admin_index.php
secret_files/
my_secret_file.txt
The webserver is only configured to serve files in the /public_html/ directory, so nobody will have access to directories outside (technical term above) it.
To still enable somebody to download those files, do as cletus suggests and use readfile to "manually serve" the files via a PHP script. PHP will still have access to these other parts of the file system, so you can use it as a gatekeeper.
Don't store the files in a directory under the document root.
Instead move them somewhere else and then a PHP script can programmatically determine if someone can download them and then use readfile() or something similar to stream them to the user.
You could also configure the Web server to not serve files from this directory but then you need PHP to serve them anyway. It's cleaner simply not to put them under the document root.
Answering question on how to password protect with PHP:
This should solve your problem.