[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers

hi jan,

On Tue, Nov 10, 2009 at 09:15:43AM +0100, Jan Hauke Rahm wrote:
> Not that I'm opposing to what you're saying but... every application in
> the archive is configured during the installation process, possibly
> asking debconf questions, providing defaults etc. After the installation
> it should run in a mode that suites most use cases and is secure. We (or
> at least I) always expected that.

i think there's some ambiguity due to different uses of the term
configuration...  i meant largely wrt the application configuration,
not the package's status wrt dpkg (though the latter probably also
implies the former).

> Now with web applications, if I read you suggestions correctly, you want
> to just throw the files in the system, leave it unconfigured without
> meaningfull defaults, even leading to an unsecure state, and then blame
> the web server for not securing the application?

the issue that i'm raising is that in this proposal the default "vendor"
docroot is on by default, and the existing cgi-bin directory has
files that are executed by the webserver without regard to whether the
application is (or is properly) configured.  therefore it will be activated
as soon as the files are unpacked and the onus is then placed on the
packager and (more likely) the local admin to make sure that this window
of oppurtunity is closed with appropriate webserver configuration after
the package has been installed.

given that there is likely a requirement for real world applications
to register themselves with a webserver anyway (for things which couldn't
"just work", extra Alias's for FHS splitting, etc), i don't see the
argument for making some subset of the package active when the larger
problem still exists and it potentially exposes the system security wise
in the meantime.

i'm not arguing against having standards and a system for getting apps to
work out of the box, in fact that's why this list was created in teh first
place.  but much of this discussion is treading over already trodden paths :)


Attachment: signature.asc
Description: Digital signature

Reply to: