News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

[4939] Package Manager tries to set permissions too high

Started by Angelina Belle, March 29, 2012, 02:36:30 PM

Previous topic - Next topic

Angelina Belle

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?
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Spuds

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)

butchs

Norv please fix it  ASAP!  Don't shock the monkey!  ;)
I have been truly inspired by the SUGGESTIONS as I sit on my throne and contemplate the wisdom imposed upon me.

Angelina Belle

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.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Norv

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)
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github


Angelina Belle

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.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

emanuele

* emanuele wonders: couldn't SMF use javascript to test permissions on a dummy file and define a "safe" highest level of permissions for the server?


Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

Angelina Belle

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.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

emanuele



Take a peek at what I'm doing! ;D




Hai bisogno di supporto in Italiano?

Aiutateci ad aiutarvi: spiegate bene il vostro problema: no, "non funziona" non è una spiegazione!!
1) Cosa fai,
2) cosa ti aspetti,
3) cosa ottieni.

Angelina Belle

Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Arantor

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.

Advertisement: