Issue information
-
#021924
-
Fixed
-
3.0.5
-
3.2.0 Beta 1
-
0 - None Assigned
Issue Confirmations
-
Yes (0)No (0)
0
Wouldn't it be a better idea to stop chmod-ing all uploads to 777?
We're a busy board with a load of uploads (750000+ files mainly through IP.Gallery). All of these uploaded files are created with 777 permissions which include execute permissions for the world. There is no need to make uploaded files executable by anyone, let alone the world. Although shell access to the server is restricted, I would argue it is better for security to create uploaded files as 660 or perhaps 664. Why not simply comply with the set umask?
I haven't tested this but I guess I could simply upload a .txt file that really is a shell script. That would already give me an executable script at the server. There is no direct way to execute it, but it's already one step in the process of hacking a server.
The permission seems to be set (hardcoded) in classUpload.php:
We're a busy board with a load of uploads (750000+ files mainly through IP.Gallery). All of these uploaded files are created with 777 permissions which include execute permissions for the world. There is no need to make uploaded files executable by anyone, let alone the world. Although shell access to the server is restricted, I would argue it is better for security to create uploaded files as 660 or perhaps 664. Why not simply comply with the set umask?
I haven't tested this but I guess I could simply upload a .txt file that really is a shell script. That would already give me an executable script at the server. There is no direct way to execute it, but it's already one step in the process of hacking a server.
The permission seems to be set (hardcoded) in classUpload.php:
@chmod( $this->saved_upload_name, 0777 );
Updating status to: Flagged For Future Version
Some servers require 777, so it's easiest to just set that since it works for everyone.
Best we could possibly do is give an ACP setting so that you can control what permissions are used. That's not really a bug though. Will FFFV this report so we can revisit at some point, as I don't see the harm in letting you decide yourself.
Some servers require 777, so it's easiest to just set that since it works for everyone.
Best we could possibly do is give an ACP setting so that you can control what permissions are used. That's not really a bug though. Will FFFV this report so we can revisit at some point, as I don't see the harm in letting you decide yourself.
In Typolight CMS they circumvent this by what they call "Safe Mode Hack", basically using a php script to FTP all the files. That works pretty good.
bfarber, on 26 April 2010 - 08:27 AM, said:
Updating status to: Flagged For Future Version
Some servers require 777, so it's easiest to just set that since it works for everyone.
Best we could possibly do is give an ACP setting so that you can control what permissions are used. That's not really a bug though. Will FFFV this report so we can revisit at some point, as I don't see the harm in letting you decide yourself.
Some servers require 777, so it's easiest to just set that since it works for everyone.
Best we could possibly do is give an ACP setting so that you can control what permissions are used. That's not really a bug though. Will FFFV this report so we can revisit at some point, as I don't see the harm in letting you decide yourself.
What servers do you speak of? Because the only thing that needs executable permissions are folders (if you don't it shows a forbidden error). On mod_php installations you need only "666" which gives full read/write access to every group, but no execute permissions. The reason for this is PHP uses the "nobody" group. WIth the situation of where PHP is running as the user, which is the case with FastCGI + SuExec or mod_php plus SuPHP, you need only 644. Configuration files should be 660.
I am for this one too.
We could have a setting for folders and files with a default option of 777 and 666.
Other could change this values easily.
We could have a setting for folders and files with a default option of 777 and 666.
Other could change this values easily.
I think I had asked the same thing a while back or so. I agree with OP's opinion. 755 or 644 is way better.
Luke, on 28 May 2010 - 01:29 PM, said:
What servers do you speak of? Because the only thing that needs executable permissions are folders (if you don't it shows a forbidden error). On mod_php installations you need only "666" which gives full read/write access to every group, but no execute permissions. The reason for this is PHP uses the "nobody" group. WIth the situation of where PHP is running as the user, which is the case with FastCGI + SuExec or mod_php plus SuPHP, you need only 644. Configuration files should be 660.
actually under suPHP or suExec with proper configuration you want 400 for normal files and 600 for configs that are written to and 755 for upload directories.
One extreme problem with mod_php on shared hosting is everyones site runs as same user, giving everyone on the same server as you access to your files.
su(exec|php) alleviates that with X00 permissions as only your user can access your files and since the PHP PRocess is RUNNING as your user, its perfectly fine.
This is true for PHP files only though sadly, since the web server still runs as nobody and it needs access to files outside of php.
The ideal solution is to have only 1 'user' for sites per box (ie still host more than 1 site if you want on a dedicated server) and make the web server run as that user with mod_php and dont use shared hosting.
Then you can 400/600/700 to your hearts content and anyone else with access to the server cant see the files.
Updating status to: Fixed
Updating severity to: 1 - Low
Issue fixed in: 3.2.0 Beta 1
I have added two constants to initdata.php, and updated IPB to use them.
Updating severity to: 1 - Low
Issue fixed in: 3.2.0 Beta 1
I have added two constants to initdata.php, and updated IPB to use them.
/** * File and folder permissions */ define( 'IPS_FILE_PERMISSION', 0777 ); define( 'IPS_FOLDER_PERMISSION', 0777 );
0 user(s) are reading this issue
0 members, 0 guests, 0 anonymous users
