[BlueOnyx:08203] Re: open_basedir bug in the SuPHP

[Michael Stauber]

Hi Jason,

> > It's a long known imperfection of our suPHP integration:
>
> Which to be fair really is a description of a bug. Given that it is known
> doesn't make it less bug like.

No, I don't think so. The *only* catch with the previous implementation was 
that suPHP used the server wide PHP settings for suPHP enabled Vsites. Which 
was still a hell of a lot more secure than just using the plain PHP support 
<shrug>. 

> Especially when this is a GUI based management system and ticking something
> in the GUI actually breaks the functionality of the component you have
> just enabled, without one having to manually add a file to fix the break.
> What makes/made it worse is that, unlike the warning in the popup note for
> SuPHP about changing site ownership, there is no warning about this issue.
> So someone like me who was unaware of it was up untill 4am desperately
> trying to figure out why my site would not work.

Just a week ago the very same issue had been discussed on this list and it was 
explained how to get around the open_basedir restriction. And I checked: The 
topic came up four times in the last 13 months and every time the limitation 
and the possible work around were openly discussed. Below are the IDs of those 
discussions and their dates:

[BlueOnyx:08102] 2011-08-15
[BlueOnyx:07258] 2011-05-10
[BlueOnyx:06363] 2011-01-21
[BlueOnyx:04974] 2010-07-07

> Your fix seems sensible and frankly the SuPHP functionality should not 
> have been offered without such a fix in the first place.

Sorry Jason, but that's simply not true. From forensics I've done over the 
last 13 months since we added suPHP support I know way too many cases where 
suPHP either actively limited the effects of exploits or prevented exploits 
outright. Or cases where it would have stopped it if suPHP had been enabled in 
first place.

Yes, it would have been ideal if the per Vsite php.ini support had been there 
from the beginning. No doubt about it. However, while the code changes that 
implemented it look minimal (http://devel.blueonyx.it/trac/changeset/741/), 
the logic behind it and the methods it uses to make it happen weren't there 13 
months ago when suPHP was initially introduced. Back then we used a 
differently compiled suPHP and our custom Perl function 
Sauce::Util::hash_edit_function() wasn't yet capable of editing php.ini files 
with such minimal effort as it can do now. So for all this to work as it now 
does, a lot of different pieces had to come together one by one.

> So you really cannot in future enable a feature that does not
> work straight from the GUI (unless there is a very clear warning or
> explanation in the GUI).

Hell, NO! Given the choice to add more security to BlueOnyx now (while adding 
a minor inconvinience during administration), or delaying things until all the 
ducks are perfectly lined up, then I'll always go for the faster 
implementation of more security now instead of "ooh-shiny!" at a later time.

> Michael, please take this in the spirit it is intended. This is great
> project and you do so much hard work on it which is appreciated by all.

Jason, I can understand your frustration, but I also see it this way: suPHP 
wasn't working for you the way you imagined it to work. You could have 
switched to regular PHP instead of suPHP while you looked for the answer. But 
instead of checking the list, where exactly that same issue had been discussed 
just last week (or instead of asking it again) you sent a rant. Even though 
the updated base-vsite with support for custom php.ini files was released 
within hours of your message (even that implementation isn't 100% perfect and 
was released in a rush) this still isn't good enough and serves as invitation 
for even more criticism. But hey, that's OK. I take it in the spirit that it 
was presented and reserve the right to disagree and to just shrug that 
criticism off.

-- 
With best regards

Michael Stauber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20110823/4a30bfe0/attachment.html>