file_put_contents() permissions

[shadowayex]

Well, I know the answer is probably obvious, but I'll ask anyway.I'm having a permission denied error with file_put_contents. I'd manually figure out what the permissions need to be, but A) I'd probably mess something up because I don't really know what I'm doing with permissions, and The scope is a little bigger than that.I'm building a file access system that is supposed to end up being a quick, easy, and secure way for people to access their files on a server from any web browser, anywhere. This system includes things like file editing, image viewing, download/upload files, file/folder creation/deletion, etc.The system is designed so you drag and drop it into the folder you want it to be able to access, usually the www folder, but could go deeper. Then, it finds and sorts all the files and folders within that directory, and also gives you access to files and folders with sub-directories, then files and folders inside them, etc.So, I need a permissions solution that can be applied within the PHP code or easily by the person using my system that will allow read and write permissions for all files/folders that are able to be accessed. But, I don't want it to completely destroy security.Is such a thing possible?

[boen_robot]

See the chmod() function, and find out how to use it by learning about UNIX permissions.

[shadowayex]

Ok, now I want an opinion.I see three main options. I can write the script so whenever it encounters a permissions problem, use chmod to the the proper permissions (which would be a 6 on one of the three, I don't know which), I can write the script so upon load of file access, it sets any permissions that are too restrictive to the level required, or, the one I'm leaning towards, get the current permissions of the files whenever I'm going to do something that requires permission, set the permissions to whatever is needed, then set them back to the original, thus leaving the original security.Judging on efficiency and security, what do you think would be best, or are they all bad?

[boen_robot]

I think the best approach in general would be to try and run PHP as a different user, depending on each account, then if permission change is required, prompt the user for it with the options of "Set and restore", "Set permanently" and "Cancel". If the change is not possible (e.g. if the current user has no permission to alter permissions of the selected folder), fail with an error.However, running PHP as a different user requires you to have full access to the web server's configuration. If you have a LAMP setup, it would also require you to run PHP as CGI, and with suEXEC to be more precise (IMHO, running PHP as a different user, and setting up permissions properly is easier on Windows Server 2008).If you must do this without full OS access, you should duplicate the OS-es role within a database, or a file to which you and only have access, store user specific privilages within it, and give your PHP full access to all folders. The disadvantage here is that if your PHP script gets hacked somehow, an attacker may be able to trick it into doing whatever (s)he wants with whatever files of whatever user (s)he wants. Doing it the OS way described above, an attacker will have to not only find a flaw in your script or PHP itself, but also a flaw in the OS itself.

[shadowayex]

Well then :)I, myself, have access to my server, but as this is meant to be a system anyone can use, it's hard to say what they can or can't do. I guess what I'm trying to say is that it needs to be able to get access, but at the same time still be portable, so others can use it.Otherwise, if I can provide some kind of file with the system that would allow run as different user capabilities, I could maybe code different ones and release different versions of the system for different OSes.It's tough to make something secure, portable, and efficient all at the same time.

[justsomeguy]

I don't see any problem with setting the permissions for all files to 0664. You can use directory security modules if you want to deny direct access to the files. For a system I'm building now, the entire folder structure and filenames are stored in the database. For the files on disk, it creates a random directory name and saves all of the files in that one directory also with random filenames, with no extensions. The database says what the original filenames were, which folders they should show up in on the interface, etc. This has the added advantage of confusing people who manage to have access to the filesystem, they can see a bunch of randomly-named things but they can't tell what type of files they are, which logical folders they're in, which item the entire folder structure is connected to, etc. They are also able to rename and move files and folders and not have to change the disk at all, only the database.

[shadowayex]

So by setting permissions to 664, I should be able to have access to files plus not create a giant security risk?I'll, of course, let those who use the system know what's going on.

[ShadowMage]

I don't see any problem with setting the permissions for all files to 0664. You can use directory security modules if you want to deny direct access to the files. For a system I'm building now, the entire folder structure and filenames are stored in the database. For the files on disk, it creates a random directory name and saves all of the files in that one directory also with random filenames, with no extensions. The database says what the original filenames were, which folders they should show up in on the interface, etc. This has the added advantage of confusing people who manage to have access to the filesystem, they can see a bunch of randomly-named things but they can't tell what type of files they are, which logical folders they're in, which item the entire folder structure is connected to, etc. They are also able to rename and move files and folders and not have to change the disk at all, only the database.

But that doesn't protect the files from someone completely erasing them does it?

[justsomeguy]

That will give read and write access to the owner and group and read permission to the public. The public actually doesn't need any permission, since reading the files always goes through PHP also.

[justsomeguy]

But that doesn't protect the files from someone completely erasing them does it?

No, that's a job for a backup system.

[shadowayex]

No, that's a job for a backup system.

Well put =)

[ShadowMage]

Well put =)

Agreed.

[shadowayex]

Although I set permissions to 664 (owner - read and write, group - read and write, public - read), I still get a permissions error when trying file_put_contents() =/The chmod wasn't able to change the permissions, and it didn't have permission to, so I had to do it by hand. The group was set to root when I did it (I'm on Ubuntu 9.10).The error given when trying to chmod was this: Warning: file_put_contents(../testFileReader.txt) [function.file-put-contents]: failed to open stream: Permission denied in /var/www/fileaccess/saveFile.php on line 10Anyone know how to either get chmod to work, or what else I need to do to get the permissions set. Remember, portability is vital.

[justsomeguy]

You need to log in as root and change ownership of the directory the scripts are in.When I install big applications, I have an installation script which creates all of the directories. When you have PHP create the directories then they are owned by PHP. If you create a directory through FTP or SSH it's owned by whatever user you logged in as, not by PHP. It's typically better to have a setup script which will create the directory or file structure for you when you install the application to make sure that everything is owned by the right user.

[shadowayex]

Ah, so make a script that creates the file_access directory, then... should it just copy files into the directory, or actually create the files and place the contents in them?

[justsomeguy]

Either way should work, I've done both with various things.