Topic: Why chmod 777 is NOT a security risk

[[Unknown]]

Alright, so say I tell you that to have attachments work properly, your attachment folder needs to be 777.  The first thing people ask me is...

  - Isn't this a security risk?
The short answer is: no, not really... it isn't.  Keep reading for the long answer.

  - So, what, you're saying EVERYTHING should be 777?!?
Not hardly.  Just some things in the forum's directory.  Not, of course, that you should do so with the entire directory - but it won't matter much if you do, so long as your server is configured reasonably correctly.

  - But... wait a minute.  The three numbers stand for "Owner," "Group," and "Everyone."  Doesn't that mean anyone can write to the files if I make it 777? (writable by all!?)
Well, technically, yes.  But, the person first has to get into your server and be able to touch the file in the first place.  They also have to have access to the directory the file is in, and the directory that file is in.  At some point, you should have a directory (probably your username) which isn't 777.

  - Isn't it safer, at least, not to use 777?  What if a hacker got in?!
If a hacker gets in and wants to cause you trouble.... there is nothing you can do.  You can have the file permissions as strict as you want, but the database will be wide open.  So, yeah... you can protect the files that don't change from being deleted, but not your posts.
Which is more important?  The files you can download again from here or the data you cannot get back?

  - Isn't it unlikely a hacker would get into my server so much they could delete posts?
Not that unlikely, but no more or less likely than if they could use 777 to their advantage.  Think of the database as ALWAYS 777.

  - Doesn't MySQL have permissions?  Can't I make it so they can't delete?
The forum won't work if you do that.  It needs to be able to delete.  If it can delete, so can the hacker.  Dillema, huh?

  - I believe you, but my host doesn't.  They don't want me to make everything 777, they say it's not safe.
So have them read this.  If they can't refute it, prove it wrong, or at least even challenge it then I guess they have to let you do 777 .

  - Even if 777 isn't a problem, why should I bother?
Because it makes things, like for example the package manager and attachments, work better.

Any other questions? (so far I made all these up, sorry if they aren't realistic .)  Feel free to ask and I'll answer away.  I challenge you to prove me wrong.... show me that somehow 777 is all that bad.

-[Unknown]

[David]

If you are on a shared server that is not chrooted on ftp or ssh login other users will be able to navigate throughout your directories.  If you have your attachments directory chmodded to 777 but its parent to 770 then they will not be able to do this as they will not be able to reach the parent.

This is how I would chmod my files and directories in a shared environment.
Read only files are 440.
Read only directories are 550.
Write files are 660.
Write directores are 770.

The ideal setup would be to have the server run in a chroot (jailed) environment.
Apache and PHP both run under SUExec.
Owner and group are both your user, since Apache runs under your user account.

If your server does not support SUExec then set the owner of the files and directories to your account and the group to the group that Apache runs under.  This still means that you can leave everyone at 0, no access, as Apache will gain access via the group.  Running in this sort of setup will not loose anything that chmodding your files to 777 allows.

[[Unknown]]

The problem is that a lot of servers are not configured properly.  But, I'll add to it that you should, by all means, have your public_html folder set to 770 or less.  But subdirectories and files can be 777...

-[Unknown]

[David]

The problem is that a lot of servers are not configured properly.

You hit the nail on the head.  Many servers do not have users and groups set correctly nor does the host really understand what they do.

[Bouminok]

How would you say - in brief terms - how a server should be correctly configured?

[Aquilo]

I'm wishing I had taking Jason's offer instead of going with the host I'm at now, I don't know what SUExec David is referring to but the one run on my host is plain STUPID!!!!

from my host...

Beyond webroot protection, which is very necessary for security reasons, we run a standard Apache Suexec setup.

why under a Suexec setup even a text file has to have 777 for a script to read & write to it? why can't 666 be good enough! right?

here is an example of the seemingly highly regarded SUExec being stupid...

an example,
I wan't a script located at
/public_html/index.php
to read and write to
/public_html/MySkins/
same user in the same account,

now MySkins contain php script so setting it to 666
should let the world read and write to it but not execute script in there this is so no one can edit the file with bad code and then execute it! this would be -rw-rw-rw- but something is making it so nothing can read the dir unless it has execute permissions.

the thing I don't understand is why I have to give execute permissions just to read!?

answer "maybe try chmod 1666?"

still overridden.

FTP log:
SITE CHMOD 1666 MySkins
200 SITE CHMOD command successful
NOOP
200 NOOP command successful
CWD /public_html/MySkins
550 /public_html/MySkins: Permission denied

if I use 1666 or 2666 or 4666 it's still Forbidden.

answer "I just changed some of the permissions on the directories..."

under 666
/public_html/MySkins <- Access

/public_html/MySkins/theme <- Access

/public_html/MySkins/theme/css <- Permission denied

and php can now execute under 666

Now I don't know if this is SUExec being stupid or the admin don't know how to run it but I don't see how any of this helps protect anything! if any thing it's undermining the hole CHMOD concept of how and who to give permissions to!

or am I wrong for thinking SUExec and this kind of setup is stupid?

[David]

If I were running a shared server I would use a chrooted environment for ftp, I would not give ssh access except on a case by case basis.  ssh would also be chrooted.  What chroot, also known as jailing, a user does is keep them in their home directory.  Instead of logging them in to their home directory but also allowing them to browse to the parent of their home directory, they won't even be able to know that there is a parent directory.  There are scripts to break out of these jailed environments but like anything, as there is a new vulnerability the software is patched.

I would then run Apache AND PHP with SUExec.  Many people believe that you can just compile Apache to use SUExec and you are set but you must ALSO compile SUExec support into PHP.  With SUExec your Apache processes will run as if they were your user.  Thus when serving one of aquilo's pages, Apache will act as if it were aquilo.  This allows a server admin to really lock down the file permissions.  No longer does the world permissions have to be 1 or 5 on parent directories since apache can now gain access itself.

Aquilo, the execute permission is used in two ways.  Either for a cgi or shell script or if on a directory it allows the user/group/world to cd into it.  You should never have to give execute permissions on a php script.  Also your host telling you to try 1666 makes no sense as the first 1 marks the file as a changed since the last backup, it is setting an "Archive Bit" and thus has absolutly nothing to do with solving your problem.

http://www.mkssoftware.com/docs/man1/chmod.1.asp

[Aquilo]

I guess the solution to the problem is to just use .htaccess and AddType text/plain .php if I don't want php run in a directory! I thought chmod would stop php from executing if it didn't have permission.

so that problem is solved, now why it has to have execute permission for anything to run!?

Thanks David!!

[Anguz]

I'm wondering about permissions right now, so I'm happy I found this thread...

one of my webhosts does jail accounts and I have a limit to the permissions I can set even, which is my problem

directories can't be higher than 755 and files 644

will it be possible to have SMF run correctly with those limitations? how?

[Spaceman-Spiff]

yes, you can have SMF running properly, but you cant use some features like:
- attachment
- package manager
- Settings.php editor (Forum Preferences and Settings)

[Anguz]

kuso~ (>_<#)

I can edit settings without the editor fine, but attachments and package manager I really want to be able to use (-_-;)

[Jeff Lewis]

one of my webhosts does jail accounts and I have a limit to the permissions I can set even, which is my problem

You need to move that site to your other host  

[Anguz]

lol that's actually what I was thinking about (^_^)

it's just that I have so much wasted space and bandwidth over there, that I thought I'd use it

[Killer Possum]

You need to move that site to your other host  

lol that's actually what I was thinking about (^_^)

*coughlewismediacough*

[Anguz]

that's precisely the other host we're talking about (~_^)

[Bouminok]

I need to move something to that other host too

[Killer Possum]

that's precisely the other host we're talking about (~_^)

Oh, right... guess I should have read those posts a bit more thouroughly

[mikeweb]

I am trying to understand, basically my YaBB SE site was fine with permissions 755 and I was able to do everything, but SMF needs to be 777 or I am limited on doing things?  Why have that change?  I think most hosts don't let you change to 777 and shut sites down for that.... and not everyone has the cash to host themselves.

[[Unknown]]

If 755 works for you, that is fine.  But on some hosts you need 777.

-[Unknown]

[[Unknown]]

More information on the above question:

http://www.simplemachines.org/community/index.php?topic=32991.msg246205#msg246205

-[Unknown]