[BlueOnyx:10167] Re: Trojans and backdoors?

[Michael Stauber]

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