Thanxs for the answer Didnt know that suphp allready fixed this problem I didn't enable suphp for my costumers In the past ist breaks several things like webmail And I believe joomla also had problems with this
Is this not an issue anymore on 5107+ -----Oorspronkelijk bericht----- Van: [email protected] [mailto:[email protected]] Namens Michael Stauber Verzonden: woensdag 18 april 2012 11:03 Aan: BlueOnyx General Mailing List Onderwerp: [BlueOnyx:10167] Re: Trojans and backdoors? Hi Steffan, > Is there any reason why below is not a standard on BO ? > >> php_flag php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f >> the-admin-username-here" While this is a simple fix, we would have to change the way how we create sites. Say you create a Vsite. The GUI page from which you do this allows you to specifly IP, host and domain name, email stuff and which services and features you want to enable for that Vsite. When you click on "save" the Vsite is created. But at that point we don't have a siteAdmin yet. So right there we cannot set the php_flag, because for it we would need to have a designated siteAdmin and we don't even have a single user for that site so far. Well, yes: The solution would be to add a couple of input fields to allow you to create a designated siteAdmin from the same page, too. On the backend it gets a bit complicated then: What do we do if the siteAdmin has his siteAdmin flag removed later on? Or if that user is suspended? We'd then need to remove the above php_flag from the Apache vhost container of that site. Or we would need to check if there is another siteAdmin available for that site und use him instead. But if there is more than one siteAdmin, then which one do we use in that case? Next there is the transitional issue: Even if this is coded, what happens when the updates are installed? Said php_flag is not set for existing VSites that have PHP enabled. So we would need to run a constructor that checks all sites if they have PHP enabled, need to check if the php_flag is already set and if not, we need to pick an existing siteAdmin of that site an have to add that line to the vhost container of that site. I can imagine a few steps along the way where this will not really work out the way we want it to. This new addition would also need to survive CMU migrations. Generally it should do that just fine, but that also needs to be verified with some testing. So yeah: This is possible, but all in all it'll be quite a bit tricky to pull off. On the up-side of things: With suPHP enabled we don't have that problem to begin with, as the email header already shows the username of the owner of the script. Hence for suPHP enabled Vsites we don't really have to set him separately with that php_flag. In fact we must not set it in a php_flag for suPHP enabled sites, as the php_flags in the Vhost container are then ignored anyway, as suPHP enabled Vsites have their own php.ini. For good measure we could also set it in the php.ini then, although that would be a bit redundant. All in all this new addition would only benefit "regular" PHP. I'll play with the idea for a bit and will see if I can come up with something. But it's not hacked together in a day or two, as it requires changes on many levels in base-vsite, base-user, base-apache. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list [email protected] http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list [email protected] http://mail.blueonyx.it/mailman/listinfo/blueonyx
