Web Developer Forum
June 12, 2024, 09:56:50 am
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Did you know - Javascript and Java are both different?
 
  Home Help Search Web Hosting & Domains Staff List Login Register  

SQL- Lesson 02 - Why chmod 777 is NOT a security risk

Pages: [1]
  Print  
Author Topic: SQL- Lesson 02 - Why chmod 777 is NOT a security risk  (Read 247 times)
Compuart
Moderator
Newbie
*
Posts: 22



View Profile
« on: September 02, 2009, 09:11:01 pm »

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 Grin.

  - 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 Tongue.)  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.

Report Spam   Logged

Share on Facebook Share on Twitter

Eliga66
Newbie
*
Posts: 3


View Profile
« Reply #1 on: January 07, 2012, 04:34:28 am »

Its VERY hard to work around in my opinion. So far Elixant is the only host that I ever used that has it disabled, and now that I am getting more and more involved with PHP and MySQL CHMOD 777 is like a MUST now. I used to did not care about it, but now it's really needed,

for example, Hope for Another Day, I had a custom codes CMS by a staff member from SSD for it, and it worked like a charm, but here it can't work, as it needed full access. CHMOD 777. Now I'm afriad I lost the files =[

755 doesn't help much at all as a lot of PHP scripts today and very recent ones need to write in the directory.

This is what I don't get, if I want to use PHP5, it has it's own database as well, but I can't use it as it can't write in the directory.
Report Spam   Logged
Pages: [1]
  Print  
 
Jump to:  

Free Website Hosting
CO.CC:Free Domain
Bookmark this site! | Upgrade This Forum
SMF For Free - Create your own Forum

Powered by SMF | SMF © 2016, Simple Machines
Privacy Policy