Portal Home > Knowledgebase > Articles Database > 777 for www ? Is this safe?
777 for www ? Is this safe?
| Posted by gpl24, 06-02-2009, 03:02 AM |
| Let me start off with saying: I haven't had any suspicious activity, nor do I think I was compromised.
I logged in as root, and was simply clicking around my dedicated server and came across a few folders with permissions at 777. ALL are above /public_html
Irregardless, is this safe? I recall reading a bunch of topics on here, that /tmp needs to be hardened. Isn't this also above /public_html?
For one example:
/var/tmp is chmod to 077
..inside is a bunch of sess_ files
Is this folder open to hacking?
|
| Posted by ZenMonk, 06-02-2009, 03:35 AM |
| Most of the public_html fall under the /home/username dir. public_html is the dir where the users would store there files and should never be 777 as the chances of users files being modifed/read/written by abusers are simply too high. Moreover, most software available these do not require your files/folder to be 777.
/tmp /var/tmp stores most of your session files only which needs to reads by the webserver, hence not a security lapse.
|
| Posted by techrudra, 06-02-2009, 03:56 AM |
| Hello,
It's depends on control panels and requirements also,
Following permissions on cpanel server:
user home directory 711
public_html 750
public_ftp 755
mail 770
tmp 755
etc 750
cgi-bin 755
www 777
Description of the permission:
Read(r) :4
write(w) :2
Execute(x):1
User Type: (UGO) User Group Other
For example: public_html permission is 750 means user have rwx permissions(all)
and group have rx permissions and other doesn't have any permissions(0).
Thanks!
|
| Posted by mugo, 06-02-2009, 06:05 AM |
| 777 is never good
The files in your /var/tmp are session files from your web users.
Your web user should have write, but does not need execute. Both together is a dangerous combo
if the owner of /var/tmp is root.root, then 776 is really all you need. (you are assigning "others" write)
"all others" should only have write, not execute.
it owner is apache.apache, for instance, then it can be 660.
7 applied to a web or "other" user gives that user, or everyone, respectively, rwx permissions, or, quantified, the ability to upload malicious script / binary and execute it
|
| Posted by adminpaul, 06-02-2009, 06:49 AM |
| Hi,
Normally all the directories set to a default permission of 755. Some applications need some folders to 777 for storing cache files or uploading images.
If the directories in question contains normal files, change it to 755.
Regards,
Paul
|
| Posted by prashant1979, 06-02-2009, 06:57 AM |
| 777 for www is never safe. It exposes the entire website to hackers. Go for 755 or stick to 644.
|
| Posted by mwatkins, 06-02-2009, 10:43 AM |
| Then don't use those applications.
Better yet, provide a list so others can know which lame apps and their lame developers can be avoided like the plague.
And to the original poster, you can take my editorial comment above as a big "no" to applying rwx permissions to "www" for user, group and others (777).
|
| Posted by techrudra, 06-02-2009, 01:18 PM |
| Hello,
Sorry for my mistyping in above reply.
Please avoid 777 permission to www folder for security point of view.
Thanks!
|
| Posted by adminpaul, 06-02-2009, 01:45 PM |
| Since /tmp /var/tmp and /dev/shm are world writable directories theyre often home to uploads, sessions storage and hacker executables. With /etc/fstab however you can limit what can be done in these locations. If you see defaults beside the /tmp line remove it and replace it with noexec,nosuid this will stop any executables from being allowed to run. Do the same for /dev/shm and make /var/tmp and shortcut (symbolic link) to /tmp.
If you are having cpanel, you can run "/scripts/securetmp" to secure your /tmp and /var/tmp.
|
| Posted by PCS-Chris, 06-02-2009, 02:04 PM |
| In a word, No.
|
| Posted by eth1, 06-02-2009, 03:13 PM |
| One can still run scripts using the interpreter,
Even though /tmp has been secured with noexec,nosuid the above workaround works.
|
| Posted by gpl24, 06-04-2009, 11:59 PM |
| What about shortcut folders? One in certain I just noticed was var/mail - when I try to change it to 0755, it just goes back to 0777; no error.
/var/clamd (file, not a folder.. was 0 bytes) was 0777, seems to have changed to 0755 without error. Not sure if this will interfere with the logging process though?
Upon closer look, /var/tmp is 1777 (sticky bit), do I change this to 1755?
|
| Posted by Beast5, 06-05-2009, 12:07 AM |
| a shortcut is not an actual file, just an inode pointer to a file.
the sticky bit is there, just to make sure no user can overlap other users open file which may break a session.
but havent you guys heard of SELinux ?- works like a charm!
|
| Posted by gpl24, 06-05-2009, 12:39 AM |
| I asked theplanet about this (I have the alpha security bundle) and I got a response within minutes, stating:
|
| Posted by Beast5, 06-05-2009, 04:11 AM |
| lol, re-read my post above.
|
| Posted by jdbravo, 06-12-2009, 12:47 AM |
| If you can install something like SuPHP or PhpSuExec, with that you don't need to have files or directories with group/others write permissions.
|
| Posted by supportexpertz, 06-12-2009, 06:42 AM |
| I don't recommend 777 permissions for any directory or files other than /tmp and soft links.
|
| Posted by krizag, 06-12-2009, 07:13 PM |
| 1777 permission with noexec, nosuid is safe for tmp directories.
|
| Posted by brianoz, 06-14-2009, 02:30 AM |
| And to take that a little further, a lot of people feel apache without suPHP/phpsuexec is unsafe (including myself). It's possible to retrieve mysql passwords without suphp, and that leads to a huge array of other possible compromises.
|
| Posted by defen, 06-14-2009, 08:13 AM |
| So an app like photoplog, which requires 777 to write images, should not be used?
Also, could someone explain this in a little more detail. My temp is actually in root, so that shouldn't be a problem, correct?
Last edited by defen; 06-14-2009 at 08:22 AM.
|
| Posted by brianoz, 06-14-2009, 08:46 AM |
| Despite what the often naive doco for packages says, you only need 777 if you don't use suphp. If you use suphp, the directory is already writable. Most developers don't know this.
What was being discussed was an improvement to security, not a problem. The problem you have is that since your /tmp is in the root directory you can't change the mount options. Only minor in any case, the protection that tweak offers is small.
|
| Posted by defen, 06-14-2009, 07:08 PM |
| Sorry for what may be a silly question, but basically you're saying that photoplog, in its current form (requiring 777 on the images folder) is, in fact, a security issue?
If I should get rid of it, does anyone know of any other good options out there?
|
| Posted by brianoz, 06-14-2009, 07:23 PM |
| Almost. As such, there's nothing wrong with the script.
If it is running with suphp, it won't need the 777 and won't be a security issue. If it's running without suphp, it DOES need the 777 and there's no option other than to run with 777. If the server is not running suphp, then the server has a security weakness, depending on it's design and configuration (it's not impossible to make a server secure without suphp, it's just very hard if it's a shared server).
To test, make the mode 777 directory mode 755 and then try to save a photo. If it fails, the server is not running suphp and is not as secure as it could be.
(I've had to simplify a couple of things here as some will realize, so as not to confuse)
|
| Posted by defen, 06-14-2009, 07:44 PM |
| Thanks, I'll give that a shot. I apologize for semi-jacking the thread. I'll just start another one if I have more questions.
|
Add to Favourites 
Print this Article
Also Read
