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

Jeff Jones jeffrhysjones at mac.com
Tue Aug 23 04:24:07 -05 2011 

What we have here - is not a serious bug, but a serious <shrug>.

Ha ha!

Jeff

On 23 Aug 2011, at 10:16, Jason Ozin wrote:

> Michael,
>  
> Your response is disappointing. Firstly my post was not a rant but a reasoned argument for not releasing broken functionality without at least an explanation/warning clearly in the GUI. But mainly because your seem to be of the mindset that all users of BlueOnyx are active participants in this list who read every post and if they are not then it serves them right if they don't know about a known serious bug.
>  
> In addition with your comment about if it's broken then simply turn it off, you are assuming that all users of BlueOnyx have the ability to debug and troubleshoot errors (keep in mind that on the face of it this is an error that just produces a blank page). Again, surely the point of having a management tool with a GUI is to assist less technical admins?
>  
> I have the greatest respect for the work you do on this product Michael but if you are seriously happy to add functionality to BlueOnyx (even one of such security benefit) knowing that the normal user will break their sites if they use it (without adding a simple warning into the GUI) then I think you need to reconsider your real world audience/users.
>  
> In short I appreciate the quick fix but it could have been implemented at inception or at the very least a warning added to the GUI.
>  
> Regards
>  
> Jason
>  
> ----- Original Message -----
> From: Michael Stauber
> To: BlueOnyx General Mailing List
> Sent: Tuesday, August 23, 2011 9:54 AM
> Subject: [BlueOnyx:08203] Re: open_basedir bug in the SuPHP
> 
> 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
> 
> 
>   
> 
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20110823/7ac47a86/attachment.html>

More information about the Blueonyx mailing list