chmod 777 may be the quickest way to get functionality, but it should never be used on a production system and I find unethical to encourage novice users to do it, even if it keeps them off the support forum. The correct way is to find out which user Pligg will be running under (www-data, httpd, www or something like that probably) and make sure that this user will have the correct permissions on the necessary files. In addition to misleading users into horrible insecurity, including such advice in a tutorial does not say anything good about the security culture of the Pligg community - you guys know better and the tutorial should advertise that !
You don't have to get so worked up over CHMOD settings. Asking users to CHMOD specific files and/or directories to allow the server to write to them is not only required for Pligg , but it's also common practice for web scripts and content management systems.
Why chmod 777 is NOT a security risk
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.
Bravenet - Articles & Tutorials / articles / Web Programming / Chmod 777 - Is it a Risk When Installing PHP Scripts?
That is also why having /libs/dbconnect.php (with the database password in it) world-readable is not a good idea, especially if the Mysql host lets that user log on remotely - it should not, but people reading that tutorial will not always be aware of that.
Confining the writing privilege to the PHP user raises the bar only a little bit, but that is another obstacle on the path to exploitation - why not have defense in depth ?
Let's assume that you can take that risk - say on a host running only software from trusted sources, dedicated to that Pligg instance or running PHP applications in isolation. Then there is theoretically no risk in leaving writable executable files lying around. But if you deployed something like suPHP to isolate PHP applications from each other somewhat, having one of them use world writable files will make them vulnerable to attack from another application on the same host. Would you bet that none of the services running on that host has any fault known or yet to be discovered that will let an hostile party write those files ? The history of application programming has taught us that even with competent people developing the software, this is quite a bit too much trust.
I feel like I'm sounding like my paranoid friends... They may have washed off a bit on me. Sites may run fine with world writable files, especially in dedicated environments. But why eschew a cheap and easy way to make an intruder's job a little bit more difficult ?
We detail in the install instructions to CHMOD the /libs/dbconect.php file to 666, and then CHMOD it to 644 after the installation is completed. This is the only file that contains sensitive information. The only other PHP files that are CHMODed are settings.php which is 666 and installation language files, which should probably be noted to be CHMODed as 666 also. And in the cases of directories being CHMOD 777 that's because most servers require that setting in order to allow the PHP to write to them.
In most professional web hosting environments security is tight enough to prevent exploits of CHMOD.
- Security risk with "chmod 777 files" versus "chmod 755 files"? | drupal.orgThe shared hosting solution I know (Plesk) uses PHP's open_basedir feature to restrict where PHP scripts can write to. For instance a script run on domain1.com can't write to dirs under domain2.com's httpdocs folder, even though they may be chmodded 777.
I have a pb in the settings of the languages in Pligg : the Language Module doesn't work... I spend 2h to fix it, but nothing works...
So I read carefully your tutorial and I found 2 lines nearly the same, one written "language" and the other "languages" ... Is this may cause a pb ???
# Rename the /language/lang_english.conf.default file to lang_english.conf. Same instructions apply to any other language file that you might use that are located in the /languages directory.
# Rename the /languages/lang_english.conf.default file to lang_english.conf
I will try to upload a previous version of pligg to see if there is a real bug in this version
I'm (obviously) an absolute, total noob at Web development, but I'm a fast learner. Since I'm so unfamiliar with the vocabulary of scripting and development, can you recommend a resource where someone with ZERO clue can learn the basics prior to attempting an install? I'd rather use something like that than ask stupid questions. I've watch the video, but it doesn't help me a great deal since he's speaking Greek to me.