On Thursday 28 October 2004 3:13 pm, Stuart Herbert wrote:
> Hrm ... I haven't made any comment on self-configuring web applications.

"We know that webapp-config needs improvements, especially in the area of 
auto-configuring web-based apps."


> > In addition, some web applications will download their own source files
> > on demand and update themselves on demand, in a manner similar to
> > Portage. webapp-config would be completely unsuitable for these
> > applications.
>
> And so is Portage ;-)
>
> Until UPSTREAM apps play nicely, this will always be a problem with any
> tool that anyone writes.  And UPSTREAM can't play nicely until there's a
> tool to play nicely with.

And in the case of the above, the tip of a sword is as close to playing nicely 
as those applications will come.

*sighs at his application frameworks*


> > In these cases, additional backend configuration is necessary
>
> The next version of webapp-config will be able to handle that sort of
> configuration too.  We need to provide a tool to do it; we can't expect all
> of our users to have the skills to secure a PHP app by hand.

I personally would not trust webapp-config to reconfigure my web server or 
modify web service configuration files, especially considering that I 
replaced the stock configurations with my own as soon as I installed Apache. 
How would you implement an automatic open_basedir restriction in PHP, after a 
web application was installed? I certainly wouldn't want my Apache processes 
receiving a SIGHUP after every software installation to reload the 
configuration, which is the only place open_basedir may be altered.

Compounding the problem, many scripts heavily modify the PHP runtime 
configuration directives: how would an automated tool be able to factor in 
all the necessary information for every web application? This doesn't seem 
realistic.

IMHO, an automated tool would never be suitable for securing a web 
environment, composed of a non-homogeneous solution of different 
applications. I simply don't see how it's possible to secure against every 
possible method of script exploitation (or even a marginal majority) for 
every web language (or even one web language), without knowing the specific 
workings of the scripts in question.

As an "upstream provider," I would also never waste my time providing the 
specifications to any tool designed for such purposes.

I can take the necessary steps to reasonably secure my web services and can 
provide information that would instruct others on how to do the same, however 
there is no way I could explain every possible combination of every possible 
scenario to every possible user on every possible configuration. It doesn't 
make sense, it's not practical and it's not feasible; the same applies for a 
unified "secure-it" tool, regardless of how idealistic the principle of its 
creation.


> > webapp-config should be completely oblivious to this, as these safeguards
> > would obviously beyond the scope of the program; however, it should
> > support the functionality if it is required.
>
> Why 'obviously' beyond the scope?

See the above.


> Every web-based app installed on practically every platform out there is
> hampered by the limited capabilities of package managers and current
> automated installers.
>
> We're going to have to get there a step at a time, but I think it's worth
> the effort.

Is it? A large number of hosting providers do not even allow their clients to 
access a shell console, nevermind Portage derivatives. In the same way, I 
would never allow one of my -client's- web applications to have any influence 
whatsoever on the operations of -my- web server. Most websites have no 
concept of a package manager, in the traditional sense: this is why my web 
applications provide their own means of filesystem management and software 
updates. At present, the only viable package management system I see for web 
applications is one they provide themselves.


> Take a look at /etc/vhosts/webapp-config and the man page for
> webapp-config.5. The support you need is there.  I don't run any of own
> sites from /var/www.

Thanks for the clarification.


> 'localhost' *is* currently hard-coded as the hostname that an app is
> installed into when USE=-vhosts.  This is something we can change.

Please feel free :)


-- 
Anthony Gorecki
Ectro-Linux Foundation