Good ol' 777 permissions

Bloke · 2011-03-16 14:31:19

Sorry to bring this old chestnut up again but even after (re)reading ruud’s seminal security write-up I’m a little confused about something. The situation is thus:

I’ve written a plugin (well, several) over the years that allow file uploads. They dump the uploaded files in some system folder (probably /tmp) and I use TXP’s get_uploaded_file() (which uses PHP’s move_uploaded_file) to shift them to TXP’s temp dir, from whence I can operate on them or move them to their final destination
On most hosts I’ve ever witnessed, this is dandy. Some, however, complain about [function.move-uploaded-file]: failed to open stream and, further, [function.unlink]: open_basedir restriction in effect. File() is not within the allowed path(s)

From my rudimentary knowledge of security, open_basedir is used to prevent PHP (<5.3) giving access to file-based resources that:

don’t match the user/group of the running process
don’t have the relevant permissions
aren’t explicitly permitted by configuration of a list of known paths

(or something like that).

I’ve been tracing through some code and diagnosing such issues on someone’s server and, long story short, it seems that the only way to prevent any warnings is to set the /tmp dir to 777. Same for /theme in the case of smd_admin_themes. I don’t currently have access to the server itself so I don’t know the permissions of the running web server processes.

I was initially confused because my plugins use the same functionality as txp_file.php and txp_image.php, both of which work. More digging revealed that both /files and /images were also set to 777 and that reducing these permissions results in failure when TXP deals with uploading images and files.

It seems to me that the host in this case has set open_basedir to “improve security” but that has resulted in us having to open up world-write permissions on a lot of resources to bypass it! Anybody have any insight into things I can do, perhaps in code, or perhaps in terms of advice on server setup on such shared hosts to catch / bypass / fix these situations and prevent my code from blowing up when someone tries to upload a file? Just prefixing all file-based operations with ‘@’ seems hackish and defeatist to me :-)

Thanks in advance for any knowledge.

Bloke · 2011-03-16 14:57:19

I’ve just been directed to an FAQ on the subject, from the host in question, and one of the solutions to the open_basedir thing is:

Use the relative path instead of the full path;

$chemin = $_SERVER[“DOCUMENT_ROOT”] . “/mondossier/”;

instead of using:

$chemin = “/home/site/www.domaine.xyz/web/mondossier/”;

Can’t for the life of me see how that will help, but if that’s a valid technique and works on non-open_basedir-inflicted servers then I’ll certainly employ it. EDIT: The main problem, iirc, with using relative paths is that trying to recursive mkdir() from a plugin requires a full path to be passed to the function each time.

The other techniques the FAQ lists include gems such as:

do CHMOD at 2777 for the folders and 0666 for the files.

Again, not sure what the ‘2’ signifies. I thought the first hidden bit was ‘sticky bit’ stuff but it’s been a while since I delved into manuals on the subject. Anyone any comments on these and what they mean for a plugin trying to write to dirs that have been set up by TXP (at install time) to 0644?

Last edited by Bloke (2011-03-16 15:03:34)

net-carver · 2011-03-16 15:22:28

The ‘2’ seems to be the group sticky bit.

Gocom · 2011-03-16 16:24:38

Bloke wrote:

It seems to me that the host in this case has set open_basedir to “improve security” but that has resulted in us having to open up world-write permissions on a lot of resources to bypass it!

Feeling your pain. I hate sevens too. Annoyingly lucky number.

Anybody have any insight into things I can do, perhaps in code, or perhaps in terms of advice on server setup on such shared hosts to catch / bypass / fix these situations and prevent my code from blowing up when someone tries to upload a file?

I wouldn’t say I’ve insights to anything, I barely have any sight at all. Codewise there is pretty much nothing you can do, other than do some condition checks and give nice little messages to the end-user that explains what they should do. Yep, ~~ugly~~ writable checks and server configuration matching.

If the 777 is actually problem depends how the server is set up. If on shared hosting some directory requires 777 permissions, contact the support. They will either explain why it’s okay, whitelist the directory or thank you for reporting an problem (and the magical 2 percent change the kid hosting the sites from grandma’s basement answers rather impolitely).

Just prefixing all file-based operations with ‘@’ seems hackish and defeatist to me :-)

You saying that I shouldn’t be starting every line with ‘@’? Ugh, what have I done. Next you are saying that I shouldn’t starts lines with cast, but rather by defining the variable. I’ve looked various reputable sources (WP) and they all use casting like that. But seriously, if you don’t like @, you can also just set error reporting completely off :p

MattD · 2011-03-16 16:30:13

The solution I found when I was on a host where file and image uploads only worked with 777 permissions was to switch hosts. Best decision I could have made.

Gocom · 2011-03-16 16:36:16

MattD wrote:

The solution I found when I was on a host where file and image uploads only worked with 777 permissions was to switch hosts. Best decision I could have made.

I would do pretty much same if it was my hosting space. I would change host. I personally try to use pretty restricted environments when it comes to shared hosting. The less rights everyone on the server has the better. There are couple things that make me instant change; permissions and too open access to server configuration.

Bloke · 2011-03-16 16:43:53

Thanks for your thoughts guys. I’d be inclinced to agree if it was my hoster: bin it and find a new one. Of course, doesn’t help my plugin from breaking under people who can’t/don’t change.

Maybe I can feel a bout of defensive coding coming on and a judicial sprinkling of @ signs after all…

ruud · 2011-03-17 13:36:28

Bloke wrote:

From my rudimentary knowledge of security, open_basedir is used to prevent PHP (<5.3) …

I think you’re confusing open_basedir with safe_mode.

It seems to me that the host in this case has set open_basedir to “improve security” but that has resulted in us having to open up world-write permissions on a lot of resources to bypass it!

Having to use 777 permissions is caused by the way the server is set up, not by open_basedir.

Anybody have any insight into things I can do, perhaps in code, or perhaps in terms of advice on server setup on such shared hosts to catch / bypass / fix these situations and prevent my code from blowing up when someone tries to upload a file?

There are three ways to solve the problem (none of which can be done in code):

use more relaxed permissions, which may be okay if you’re the only one on the server (not necessarily a dedicated server; a VPS will do just fine), but is a bad idea in most other situations.
fix the server setup: which mostly isn’t possible on a shared server, unless you are the server admin, in which case there’s plenty documentation around that shows how to properly set up a shared hosting service in a somewhat secure way.
switch to a different web host.

Just prefixing all file-based operations with ‘@’ seems hackish and defeatist to me.

That doesn’t really solve anything. It just suppresses the error messages and leaves the user wondering why it doesn’t work. And ‘@’ brings you a small speed penalty as well.

Bloke · 2011-03-17 14:05:47

ruud wrote:

I think you’re confusing open_basedir with safe_mode.

Entirely possible. As you can tell by my posts, I haven’t even reached the lofty heights of ‘novice’ when it comes to web hosting security.

There are three ways to solve the problem (none of which can be done in code):

Well that’s me off the hook then :-)

Actually, I was coming to that conclusion myself. Now I just ‘@get_uploaded_file()’ and check if it returns false, then check the file size, then check the file format, and if anything fails issue an error at each stage with a suggestion to check permissions with your host. I suppose it’s technically better to let the errors fly so at least someone can report the messages, albeit less pretty.

What I might do in future is keep the error suppression on but allow it to be removed if the plugin is put in debug mode. That at least gives a path for diagnosis in the event the plugin throws one of my warning strings.

Thanks for setting me straight on this topic. Much appreciated.

Last edited by Bloke (2011-03-17 14:07:17)

linguist · 2012-10-19 09:38:51

Hello! I posted a similar question in a new thread, but maybe my question will have more luck here. I would really appreciate your advice on this matter. Thank you. (Should I delete my other post on this subject?)

My hosting provider recently started using Apache module ITK (mpm-itk), and as a result everything now runs with the owner’s permissions. Hosting support says that this is completely safe if my CMS does not have any security problems. They also suggested that if I’m worried, then I could change permissions to 555 where needed. If I lower permissions as suggested, would Textpattern work? (I have TXP4.5.1)

Last edited by linguist (2012-10-19 09:42:32)

ruud · 2012-10-19 16:32:53

Try 600 for files, 700 for directories. If Apache is accessing the files/dirs with your owner permissions, then that should be enough. 400 for files may work as well (only read permission). For some dirs that don’t require changes (unlike the image/files dir) you can probably use 500. If it’s a directory where you only need to read the files and know the file location (and thus don’t need to list the directory contents), perhaps even 001 will work.

linguist · 2012-10-19 21:29:42

Thank you for your answer, Ruud. I really appreciate it.

Textpattern CMS

Textpattern CMS support forum

#1 2011-03-16 14:31:19

Good ol' 777 permissions

#2 2011-03-16 14:57:19

Re: Good ol' 777 permissions

#3 2011-03-16 15:22:28

Re: Good ol' 777 permissions

#4 2011-03-16 16:24:38

Re: Good ol' 777 permissions

#5 2011-03-16 16:30:13

Re: Good ol' 777 permissions

#6 2011-03-16 16:36:16

Re: Good ol' 777 permissions

#7 2011-03-16 16:43:53

Re: Good ol' 777 permissions

#8 2011-03-17 13:36:28

Re: Good ol' 777 permissions

#9 2011-03-17 14:05:47

Re: Good ol' 777 permissions

#10 2012-10-19 09:38:51

Re: Good ol' 777 permissions

#11 2012-10-19 16:32:53

Re: Good ol' 777 permissions

#12 2012-10-19 21:29:42

Re: Good ol' 777 permissions

Board footer