On Thursday 28 October 2004 23:52, Anthony Gorecki wrote: > 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." That's auto-configuration, not self-configuration. There are web-based apps out there with their own (normally web-based) configuration support. That's what I'd call self-configuration. > 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* That's true today. It'll stay true tomorrow if no-one does anything to try and change it. But if we try - who knows what we can achieve? > 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? open_basedir can only be set in php.ini or the Apache config file. It's always best to avoid setting anything other than system-wide defaults in php.ini. I'd do what I do on my boxes at work. I'd create a per-app-instance config file which contained the necessary settings, and have apache include it the next time it was SIGHUP'd. How would I decide whether an open_basedir restriction was required? That is a policy decision, which would be managed through the vhost-tools. > 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. The SIGHUP is required for a change to take effect. That doesn't prevent any tool from putting the configuration in place ready for a scheduled change. Again, scheduling config reloads is a policy decision, which could be managed through the vhost-tools. > 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. You're assuming that the tool has to learn about each app, me thinks. That's not what I intend to do. I'm intending to provide tools which will generate config files for the various apps - and which will get the information from config files maintained by the local administrator. There aren't that many scripts that modify php.ini - and any script that does is (as far as I'm concerned) broken. > 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. I hope to prove you wrong in time. > As an "upstream provider," I would also never waste my time providing the > specifications to any tool designed for such purposes. I'm sorry to hear that you think it's a waste of time to try and improve the ease of installation of your packages. > 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. Why are there so many scenarios where your services would be insecure? > It doesn't make sense, If it's too complicated to do by hand, then it definitely needs automating > it's not practical and it's not feasible; When was the last time you installed a Windows application by hand? Or a non-web-app on Linux? Most apps in the world can be installed automatically; there's no reason why web-based apps should be treated as a special case. > 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. My experience is different from yours. Aside from the '50Mb free with your dial-up account' type hosting, most of the hosting over here in the UK provides shell access. It's not possible to support non-privileged users running webapp-config with the default Apache 2 MPM, as these users can't perform the chown operations that the tool needs to do. We could provide a setuid-safe script to do this, but that's not top of my todo list. The problem with each web-based package providing its own package management is that you're left with widely varying quality. You also have the problem that it's harder to lock down a site and prevent unauthorised change. And these tools don't work too well on secured and/or disconnected intranets (and these are surprising common in the public sector at least). Tools that extend Portage - tools that allow for disconnected upgrades - still have their advantages :) What you describe is how things are today. If the tools existed to do these things for you, would you still want to live in today? Even if you do, there are plenty of people out there who do not. Best regards, Stu -- Stuart Herbert stuart@gentoo.org Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C --