FTP Policy Change - Problem!

[electprogeny]

In many of my sites I have hosted on Powweb I have to set permissions to folders and files during installation and upgrades. With this new policy change disallowing us to do these necessary changes - you knock out a tremendous number of applications, including basic content management systems.

In almost all cases the directories where these changes get made are required to be deleted before the installation or upgrade is completed - so your policy effectually makes your hosting service impossible for me to use the first time I am unable to install or upgrade by using 755. Please reconsider this policy.

[IanS]

In many of my sites I have hosted on Powweb I have to set permissions to folders and files during installation and upgrades. With this new policy change disallowing us to do these necessary changes - you knock out a tremendous number of applications, including basic content management systems.

In almost all cases the directories where these changes get made are required to be deleted before the installation or upgrade is completed - so your policy effectually makes your hosting service impossible for me to use the first time I am unable to install or upgrade by using 755. Please reconsider this policy.
Instead of giving a general statement about 'a tremendouse number...' can you give a few that won't work with the current settings.

Specifically, which ones require 777 or 666 that don't work with the alternative 755?

As you say this is a tremendous list, shorten it to maybe 10 or 20! :D

[dlammers]

phpwebsite, which I just switched over to for one of my domains, needs 777 directories for its photo album subdirectory and a few other modules. Is there a workaround here?

dlammers

[IanS]

Have you tried settings of 755 as suggested?

[mprovost]

Installers should still work. We didn't disallow the chmod 777 command; the FTP server just ignores the world writeable bits. So if you chmod a file 777, it will be 755 on the server but the FTP server will still report a successful operation, not an error. No program should 'require' 777 files or directories. That means that anyone else on the server can add or delete or change your files. This has been the cause of most of the 'hacked' websites that you see listed here on the forums. Most of the time this gets done by accident, so we're being proactive and protecting against a common mistake.

[eslgate-com]

Hi, I use php-nuke v7.2 portal with esmgallery module and i have to do images folder in 777, so this with this server isn't possible to do 777, and with the 755 send the pictures doesn't work, what can i do or what I can use like pictures gallery with the php-nuke v7.2

Thanks for help...

:confused: :confused: :confused:

[mprovost]

I don't know about that module but php-nuke uses 755 permissions.

http://phpnuke.org/modules.php?name=PHP-Nuke_HOWTO&page=permissions.html

This page has some more info:

http://phpnuke.org/modules.php?name=PHP-Nuke_HOWTO&page=permissions2.html

If you have a module that requires 777 permissions I would seriously advise against using it. That is how so many of our customer's forums get hacked.

If you absolutely need to have 777 permissions, remember that this restriction only applies to FTP and you can still change permissions on the system.

[tbonekkt]

Think of it this way - this change is just like attempting to CHMOD anything below 600; i.e. 444 like osCommerce requires. The FTP daemon won't allow it, so you just need to use a custom script or SiteTools in OPS to perform the CHMOD.

Even though it is still possible to use 777, we HIGHLY advise against it.

[linnetwoods]

Ooops... wandered into your blog and lost a couple of hours there, tbonekkt... I discovered the archives... couldn't get to your wedding photos though... then I discovered your tool thingy and I thought you might like to see this...me (http://www.linnetwoods.com/webmaster/temp/me.gif) :D

[ccbrooks]

Hi all -
I've been reading into the chmod policy change a bit, trying to figure out a way around the issues that pop up without mode 777 available.

So here's my question: If I want to install and use Gallery2, how do I give the webserver permissions to write its database folder if I can't change folders to 777? Just using 755, can someone tell me what the workaround is?

Right now, with all folders set to 755, the Gallery2 configuration program will stop and give an error that the database folder (g2data) cannot be written to.

Thanks in advance for your help -

Chris

[IanS]

Earlier in this thread Tom gave the answer:
http://forum.powweb.com/showpost.php?p=349889&postcount=9

[ccbrooks]

Hi all -

please ignore my last post... for reasons too boring to relate here I had both an "installer" and an "upgrader" for Gallery2 uploaded onto my site - I was trying to use the upgrader instead of the installer when i got the errors -

using the Galler 2.0.2 installer, you *can* use filemode 755 instead of 777. I have it installed now...

thanks for everyone's patience -

Chris

[davidjaymz]

Think of it this way - this change is just like attempting to CHMOD anything below 600; i.e. 444 like osCommerce requires. The FTP daemon won't allow it, so you just need to use a custom script or SiteTools in OPS to perform the CHMOD.

Even though it is still possible to use 777, we HIGHLY advise against it.

Does this still hold true?

I'm using Expression Engine (http://pmachine.com) and we need to be able to set the following CHMOD rules.

You must set the following files to 666:

* path.php
* system/config.php
* system/config_bak.php

You must set the following directories to 777:

* images/avatars/uploads/
* images/captchas/
* images/member_photos/
* images/pm_attachments/
* images/signature_attachments/
* images/uploads/
* system/cache/

Now I've just tried this in ops. site tools and it hasn't changed the chmod value visible in ops.

If this is impossible to do it looks like i may have to choose between EE and powweb...

Asking on the EE forum about these new changes most responses I got where along the lines of "leave them".

Rick Ellis one of the founders of EE replied


There’s only one reason a server admin won’t allow their users to set their own permissions: They are not confident in their ability to secure their own servers. If your server is set up correctly and you run a script with a security hole the only thing that can be damaged are your own files. In essence, your host is trying to protect you from yourself, and cover their backside if they haven’t secured their server properly. If it was me I’d run, not walk, to another host.

You can read the rest of the thread here . http://www.pmachine.com/forums/viewthread/29117/

As I said if this can't be resolved I fear I'll be looking for a new host.

Is anyone at powweb willing to help me rectify these issues or confirm why only powweb (that i know of) has implementated this ban?

[IanS]

Does this still hold true?

I'm using Expression Engine (http://pmachine.com) and we need to be able to set the following CHMOD rules.

You must set the following files to 666:

* path.php
* system/config.php
* system/config_bak.php

You must set the following directories to 777:

* images/avatars/uploads/
* images/captchas/
* images/member_photos/
* images/pm_attachments/
* images/signature_attachments/
* images/uploads/
* system/cache/

Now I've just tried this in ops. site tools and it hasn't changed the chmod value visible in ops.

If this is impossible to do it looks like i may have to choose between EE and powweb...

Asking on the EE forum about these new changes most responses I got where along the lines of "leave them".

Rick Ellis one of the founders of EE replied
There’s only one reason a server admin won’t allow their users to set their own permissions: They are not confident in their ability to secure their own servers. If your server is set up correctly and you run a script with a security hole the only thing that can be damaged are your own files. In essence, your host is trying to protect you from yourself, and cover their backside if they haven’t secured their server properly. If it was me I’d run, not walk, to another host.

You can read the rest of the thread here . http://www.pmachine.com/forums/viewthread/29117/

As I said if this can't be resolved I fear I'll be looking for a new host.

Is anyone at powweb willing to help me rectify these issues or confirm why only powweb (that i know of) has implementated this ban?
Have you actually tried running the scripts with the settings that are allowed?

I would expect a competitor to rubbish the actions of Powweb - certainly I'd not expect them to praise them if there own systems were insecure!

[tbonekkt]

Does this still hold true?Partly - I just discovered that SiteTools won't allow it either; however, a custom script I just wrote did.

[extras]

They must be checking hard coded 777 and/or 666 in the script ....

They should check if it's writable or not, and it should work on both secure setting like PowWeb
and insecure mod_php setup (for shared hosting).
http://ca.php.net/is_writable

[davidjaymz]

Ian. Yes I did try. No-go. I wouldn't call pmachine a competitor. They are a CMS company first, webhost second. This is not about them trying to get me to leave powweb and go to pmachine hosting. This is about a host setting a requirement that a lot of people in dev world think is Unnesessary.

Tbone, Any chance of sharing the custom script? I'd like to stay at powweb but this could be make or break.

Extras I'll raise your comments over on the board. Thanks for the helpful reply.

[tbonekkt]

Tbone, Any chance of sharing the custom script? I'd like to stay at powweb but this could be make or break.Sure:<?
// Change this.
$fullpath = "/www/u/username/path/to/dir";

// Change this as needed - the first zero is necessary.
$mode = "0777";

if ( chmod($fullpath, $mode) ) {
echo "Successfully set permissions on <tt>$fullpath</tt> to <tt>$mode</tt>.";
}

else {
echo "Error!";
}
?>

[davidjaymz]

Hi Tbone...
Thanks for providing the script. Although I'm not sure if i'm doing it right cos it doesn't seem to be working.

I've put the code in a php file and am surfing to it on the server.

I've got a subdomain setup called core which i've done by putting a folder called core above htdocs and then a htdocs folder in said core folder.

The path in the php seems to be correct because the script isn't giving an error.
However it doesn't seem to be performing the correct CHMOD change. When i run the file it appears to chmod path.php from 644 (default upload value) to 232. This is visiable in both my ftp client and the sitetool file explorer.

Is this something you've experienced before? Just to check it wasn't a sub domain problem i tried it on a file in the original htdocs and got the same result.

As always any and all help is appreciated.

<?
// Change this.
$fullpath = "/www/u/username/core/htdocs/path.php";

// Change this as needed - the first zero is necessary.
$mode = "0666";

if ( chmod($fullpath, $mode) ) {
echo "Successfully set permissions on <tt>$fullpath</tt> to <tt>$mode</tt>.";
}

else {
echo "Error!";
}
?>

[davidjaymz]

Anyone? Please. I can't be the only person having real issues with powwebs policy change.

[tbonekkt]

Weird.. the chmod() step doesn't like using a variable. Use the following instead:<?
// Change this.
$fullpath = "/www/u/username/path/to/dir";

// Change the CHMOD setting to the desired result.
// The first zero is necessary, ie 0666

if ( chmod($fullpath, 0777) ) {
echo "Successfully set permissions on <tt>$fullpath</tt>.";
}

else {
echo "Error!";
}
?>

[mprovost]

Just to reply to the quoted post from EE above:

"There’s only one reason a server admin won’t allow their users to set their own permissions: They are not confident in their ability to secure their own servers. If your server is set up correctly and you run a script with a security hole the only thing that can be damaged are your own files. In essence, your host is trying to protect you from yourself, and cover their backside if they haven’t secured their server properly."

We're not doing this to protect ourselves, it's to protect our customers. Most of the hacks that you see people complaining about on this forum are caused by incorrect permissions. It doesn't affect anyone else on the server, but many people set their permissions to 777 because it's easy and then have their site get hacked.

They want you to make all the image directories for your program set to 777, so anyone else can copy, delete, modify or upload photos into your directory. Not only that, since they can modify them, they can potentially just replace an image with a PHP or perl script, and now that script is running with your permissions, so it can modify any part of your site, even if those parts of the site have correct permissions. So they can easily deface or replace your front page, grab your database passwords, etc.

So he's right - the only thing that can be damaged are your own files. Are you willing to install software with such a large security risk? We've tried to make our servers enforce sensible precautions so that people can't make a simple mistake and leave their sites vulnerable. Many people don't understand Unix permissions and incorrectly set things to be world writeable. If you really want to work around it, there are plenty of people here willing to give you ammunition to shoot yourself in the foot.

[extras]

This is about a host setting a requirement that a lot of people in dev world think is Unnesessary.
I don't agree with this part.

First, these "dev" people seem to know little about security issues ....
The problem occurs only when they try to enforce "unsecure" permission setting,
which isn't needed nor wanted at many of major shared hosting providers.

It's a BUG of the setup script, IMO.
And they should be able to tell you which line in the script is checking the permission.
Then, you can simply comment out that part, most probably.

If not, you can set the permission of the directory to unsecure 777 during the setup by a script,
and put it back as soon as it goes through..

[korik110]

I'm in the process of looking for another provider because of this change. On my webpage we use something called EQDKP which requires we be able to set permissions to 777 and 666. This is something used by almost every online gaming guild and is an absolute necessity to have.

Specifically what has to be done is the following:

Telnet to you site and change directories to the /template directory and enter the following command from your $ prompt:
chmod -R 777 templates/cache

and

Telnet to you site and change directories to the /template directory and enter the following command from your $ prompt:
chmod 666 config.php

Without having it configured this way EQDKP simply won't work. You can't even access the config panel to use half the options.

I would prefer to not have to move to a new provider. I have been a powweb customer for several years now. But if no option is given to deal with this issue I simply can't keep my guild's webpage on a provider that doesn't allow us to use one of our most important features.

Thank you for any help you can give.

[IanS]

I would prefer to not have to move to a new provider. I have been a powweb customer for several years now. But if no option is given to deal with this issue I simply can't keep my guild's webpage on a provider that doesn't allow us to use one of our most important features.

Thank you for any help you can give.The way I've understood many of the posts here (especially by Tom) is that the settings can be made, but you've got to be prepared for both the consequences and to do a little work to make the settings on folders/files that you 'need'. You can't do it via FTP but can with a php script.

[andi_sf]

I am also looking into alternative web hosting since not being able to CHMOD 777 which is required by a lot of scripts simply makes my life more difficult than it needs to be - why jump through so many hurdles when this feature is available at any other web hosting company?

My question to Powweb - why alienate so many users and affecting your business negatively with such a change???? All and much bigger web hosting companies allow this features so it can't be a security risk if the server is set up properly.... I think if you bring back this feature you avoid loosing a lot of business...

[IanS]

I think they have answered your question as to why. They feel that the novice shouldn't be using that setting and the expert still can. I don't agree that it is affecting business negatively - only a few have complained and even less have actually come out and stated the script that doesn't work with the alternative suggested settings.

[tbonekkt]

Dealing with hundreds of emails and calls to Support regarding exploited sites due to these two permissions is what prompted this change in addition to the desire to protect our valued clients. You've got to understand it is never an intention to take away features or capabilities; however, the effects of the capability is taking a toll on our efficiency in dealing with problems that are really ours. Exploited sites through insecure permissions aren't our responsibility, and unfortunately many use scripts deem these permissions "required" (even if they're truly not).

In a perfect world, all users would be educated on permissions and their respective security levels, script writers would fully understand permissions and what is actually needed, and no one would try or succeed in exploiting scripts. But this isn't a perfect world and all three of the above scenarios occur on a daily basis.

There's nothing improperly set up on the server. As I've pointed out in this thread, it is definitely possible to continue using the two permissions. Yes - it is harder to do so now. But as Matt so eloquently stated, you'll probably end up shooting yourself in the foot by doing so.

[davidjaymz]

Wow. Thats a lot of replies.

Apologies for getting a bit uppity. TBone. That new script works fantastically. Thanks again.

Mprovost. Thank you for stepping with powwebs standing on this. And i understand your point of view. I appreciate that "closing" these loop holes will stop a lot of people being hacked. But some of us have to bow to the greater knowledge of the people coding the CMS's we use that these settings have to be made.

I will however direct the coders of EE over here so they can read your comments and maybe think about their implementations of 666 and 777

Thanks again for all the help and I'm happy those of us who want to can still make these changes

Thanks Tbone.

DJ

[tbonekkt]

Glad you're up and runnng. :)

[MysticTiger]

Thanks for the custom script. I used it and it works great for me, also. This is a real site saver for me, since I have a user gallery and custom avatar options for my site.

[missyvortex]

I have a fairly annoying problem due to the change, I wasn't aware of it until I tried to fix a bug after upgrading my efiction (http://efiction.wallflowergirl.com/) install to the latest version. Looking for what was wrong I discovered a file needed 666 only ftp wouldn't change it to that of course. 755 did not work as an alternative and this means I can't use subcategories on the archive, which is pretty serious for it really. :(

[davidjaymz]

Missy. Check out the script further up this thread and you'll be able to set your chmod's to 666 as needed.

[mprovost]

I looked at the efiction software and it looks like it sets a lot of permissions insecurely, even after installation/upgrades. 666 is almost as bad as 777 - it means your files are writeable by anyone. You should contact the authors and see if they'll update their software to fix this security hole. You can get around the installation problem with a script, but you're just opening yourself up for problems in the future.

[Calash]

You can do a database install of eFiction fine with 755..done several for my site both upgrades and new installs. Everything on my site is currently 755 or 644, so far no errors.

I can not speak for using files to store the stories, I have always used the database :)

[chrparis]

Hello. I'm new to all this PHP stuff and I'll probably have problems with this change. Anyway, almost one week ago, I installed, not from site tools, but manually, a WordPress version 2. Do I've to change my permissions? I hope no, coz Ill get confused, lol

[Yukino]

i'm not sure exactly to go about implementing this script that was posted. i'm not used to having these kinds of restrictions on my files...

i know my image galleries are going to have be looked at as they use 777 as well as my postnuke... and i'm trying to implement a new efiction script. and i have tried as many ways as i can think of to get around that 666 initial install but i don't see one...

so if anyone can help me with this work around script and where to install it and to have it work with multiple folders/ files in folders that would be great...

otherwise i to will have to go looking for another provider... and i was quite happy up until this point...

[stevel]

You should look for another script. 777 for a protection is like putting a big "HACK ME!" sign on your site. Either that, or try the suggestions posted here about using a more restrictive permission. Any file activity done by your own site scripts needs only 700 protection.

[Yukino]

i do not want to look for another script. the fact that powweb is now basically telling us what to run on our own websites is really agrivating. it is a customers own choice on how they want their files set. and in inital installing and some updating those are nessecary.

all i wanted was clarification on how to go about implementing that script. not to be told i shouldn't do it as it's unsafe, i read over the reasons why powweb implemented this and i don't agree with them. so i want to use the script just wasn't sure how to go about doing it as i had never done it before. so if someone can help me on how to run that script great! i would appreciate it. but if it's just going to be replies that if i don't know then i should just scratch all the stuff i use on my site don't bother.

thanks in advance to anyone who can assist me!

~a very frusterated powweb customer

[stevel]

Have you actually tried the script with a folder protection of 755?

[tbonekkt]

i do not want to look for another script. the fact that powweb is now basically telling us what to run on our own websites is really agrivating. it is a customers own choice on how they want their files set.We're not telling you what to run on your sites. We're simply setting limits on our services to serve the greater good. Setting something to 777 can not only affect you but everyone else within your cluster. That's the nature of shared hosting.

Would you like it if all your time, effort, and hard work were destroyed/defaced because someone else chose to use an insecure setting?

[Yukino]

Have you actually tried the script with a folder protection of 755?


i don't see a problem with the 755, i haven't tested it on all my scripts that use it yet though. the thing that's getting me is that i have a couple files that need to be 666 in order to do some initial install/upgrades. without that i'm hooped.

[davidjaymz]

using the script is very simple.

Just change the path to the file you want to chmod. change the code to the chmod code you need. 666 755 whatever

upload to your website. anywhere. surf to it and it'll run and perform the chmod.

Change the path and the CHmod to the next file upload again and surf to again and there's your second file.

repeat al infidium

If i knew more coding i'd probably try to wrap it in a script where i can do multiple files at once. but i don't so...