Package Manager, when it runs into any troubles, tries to set permissions as high as possible.
But on systems with suexec or suphp, this can be inappropriate:
http://www.simplemachines.org/community/index.php?topic=227599.msg3302865#msg3302865
For example.
If file permissions are set higher than 644, some hosts start throwing 500 errors.
Package Manager prefers to set permissions much higher than that.
And, for good reason, in some cases.
There really are two cases, aren't there? The case where php runs as the webserver-user, or no-one, or the case where php runs as the user owning the containing directory? SMF cannot detect this, but SMF could have a way for the user to say "My host does not permit such high file permissions. PLEASE don't set my permissions so high". And make its decision based on a setting, rather than trying to ratchet up the permissions a couple of times?
Yes, well the whole thing is a bit of a mess really.
But in short, yes if you get permissions set to high (read loose) on a PHP suExec system you will get a 500 error, 777 will do it for sure, had not heard of a 755 doing that but who knows, I can see that as well in some systems.
I know for a fact that Norv signed up to fix this in 2.1 (OK that is a bold faced lie, but if we all say it enough it will become fact and then Norv will be shammed into fixing it :P)
Norv please fix it ASAP! Don't shock the monkey! ;)
File permissions higher than 644 or 655, depending on the host.
Directory permissions higher than 744 or 755, also depending.
Permissions set based on a setting.
Thanks.
Quote from: Spuds on March 29, 2012, 09:02:15 PM
Yes, well the whole thing is a bit of a mess really.
But in short, yes if you get permissions set to high (read loose) on a PHP suExec system you will get a 500 error, 777 will do it for sure, had not heard of a 755 doing that but who knows, I can see that as well in some systems.
It happens for 755, too, sure, if the suExec limit is set to a "lower" allowed permission. The server settings can cover more cases, it's not about 644/755 vs 666/777 only: you can set 600/700, and there are systems set up with this limit, including my own servers, for example. It's more secure. And for any "higher" (= more "loose") permission on a file or folder than that, it will fail with a 500 error.
Indeed SMF will usually try 644/755, then 666/777, ignoring completely other options (and even that has some other buggy behavior, heh). This is why a setting wouldn't help that much: SMF could avoid to set 666/777, okay, but it will only help for some particular case of server configurations (and it may do the same thing anyway even for "passing" from 644 to 655, not to even mention "lower", though again 655 is not really meaningful). Although I can see it may seem a common case, but since I've seen reports that 600/700 limit is also used on widely available shared servers, it still comes down to: hardwiring a setting, to a lot of hardcoded values used throughout package manager functions, only to cover a case.
I suppose I can see why those values were used years ago, when it must have seemed that the common case above is an "uncommon case" and that almost always 666/777 would work and was working, on shared hosts. Although it's the most unsecure case, but it was common... :(
But today, surely the whole assumptions and implementation of package manager permissions need reconsidered.
Quote
I know for a fact that Norv signed up to fix this in 2.1 (OK that is a bold faced lie, but if we all say it enough it will become fact and then Norv will be shammed into fixing it :P)
:D
Yes, I've actually worked on these issues with the over-enthusiastic Package Manager, this is only one of the problems with it. I'll make a backport in 2.0.3 too, as appropriate. It will need serious testing on various configurations, though.
Which must be why I also heard that SpudsMan offered to package the backported commits once done, into a package we will make available for testing to the community, before 2.0.3. (no, I didn't hear that, but it's almost like he did, so it counts! :D)
Have it tracked: http://dev.simplemachines.org/mantis/view.php?id=4939
:)
Thanks.
I think a setting could help -- if a forum owner KNEW which CHMOD were "too high" for that particular forum, and entered those values, then PacMan could know NEVER use CHMOD greater than these settings.
/me wonders: couldn't SMF use javascript to test permissions on a dummy file and define a "safe" highest level of permissions for the server?
Instead, perhaps a one-time test to create some dummy files, then use javascript to attempt to load them and check for 500 errors, then store the results as settings.
yep, exactly what I was thinking. ;)
I understand now. Yes. And save the setting.
Closing this, retracking centrally under https://github.com/SimpleMachines/SMF2.1/issues/1276
That report links back here and means that when we tackle it, we can find all the relevant information easily.