Re: [gentoo-dev] apache eclass

[Ned Ludd <solar@gentoo.org>]

Aside from all DocumentRoot stuff I feel that one of the most important
things that needs to be addressed by any apache.eclass is what version
of apache are we using 1,2 when ~arch flags are set. I was reently very
unhappy to find out that apache2 got installed on one of my production
servers after doing an upgrade world when -apache2 was explicitly set
and the box previously had apache1 installed. 

A FORCE_APACHE=1|2 option was mentioned the other day here on the ml, I
support that idea fully.

What I would like/hope to see is for carpaski to make the final decision
if any sort of dynamic method should be used to gain the apache
docroot,user,group, and other runtime settings. Then hopefully one of
you (Brad Laue comes to mind as it looks like he was willing to step up
to the plate) will parent the needed {apache,http}.eclass

> > Have a look at http://bugs.gentoo.org/show_bug.cgi?id=20642 with regards to
> > automatically determining DocumentRoot.
> > Synopsis is that a simple grep breaks configurations that use virtual hosts.
> > Reliably detecting the doc root on all possible installations is very hard
> > indeed.

Thus why the example code only extracted the very first case of
DocumentRoot out of the conf and ensured there would be no extra
whitespace/tabs something that a simple "grep | cut " can not address
correctly. I also feel the logic I used is for the example code to get
the docroot is sane (other than UPPER vs lower case, but that could be
addressed by using grep -i). I suppose one could do more and add the
extra step to ensure that the document root really does exists.
[ ! -d "${DOCUMENT_ROOT}" ] && die "some clever error msg here" 

Note: I'm not 100% sure that we can die correctly from within an eclass

> > After discussion with others, my recommendation is that the document root
> > should always be /home/httpd/htdocs. You could allow this to be overridden
> > with DOCUMENT_ROOT= in /etc/make.conf if you're feeling generous.

This is what I would really like to see in the end result.

> Actually, in a further discussion today in #gentoo-dev, we noted that
> detected the DocumentRoot or allowing to be variable in any fashion 
> causes more serious problems with tbz2 binary tarballs.
> For example:
> DocumentRoot is /var/www
> User builds a web application, which installs to /var/www. The tbz2
> contains files with that pathname component in them.
> Now DocumentRoot gets change to /home/httpd/htdocs (any number of ways,
> including emerging the binary package on a different system).
> User tries to install the package, telling emerge to use the
> pre-existing binary.
> Package is extracted to /var/www, which is never looked at by the
> webserver.

I feel one of the really great things about gentoo is its flexiablity,
users can build there systems exactly how they want when they want.
Having such variables in an eclass that can be overridden by the enduser
at compile time to me seems by far the best option for our users. I have
faith that "most" of gentoo's users that would edit such an option would
know what there doing in reguards to there own DocumentRoot.

> 
> Because of this DocumentRoot must be totally static.
> If we ever want DocumentRoot to be variable, somebody has a LOT of work
> to do with apache config parsing.
> 
> In cases where users want a different DocumentRoot, I would suggest that
> the packages are all installed in a fixed location (not nessicarily even
> in the DocumentRoot directory), and then the user can symlink them into
> their own DocumentRoot.
> A possible solution:
> All webapps install to something NOT inside DocumentRoot.
> 'ebuild /usr/portage/.../foo.ebuild config' sets up the application
> (needed in most cases already) AND puts in a symlink to the
> DocumentRoot.
> This also makes it easier to support virtualhost configurations that all
> have access to a common tool, and makes temporarily disabling an
> application for security reasons much easier to do.

For security reasons I see that as having both pros and cons. 
You addressed the pros, I will address the only con I can think of off
the top of my head. This type of setup would require that FollowSymLinks
must always be set which could potentionaly introduce new security holes
depending on the app thats being installed.


Another thing which was not addressed by the example eclass is what
permissions should webapps install as. I notice a few ebuilds are making
everything owned by apache.apache and are world readable. I like would
suggest that when you (any dev) dont know what permissions to use try
and make the files root owned apache readable and other non -rwx
readable,executable,writeable
(-rw-r----/0640) root.apache This would keep all users expect the apache
user itself from reading misc the misc php,perl scripts which sometimes
contain things like mysql passwords. Granted crafty local users could
get around those permissions pretty easy to extract passwords but it
would improve the overall security of installed files. And when a webapp
says its needs to be mode 666 (laugh to yourself and try to make the
file apache owned with 0600 or 0660)

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux (Hardened)


--
gentoo-dev@gentoo.org mailing list