From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24086 invoked by uid 1002); 12 Jun 2003 17:31:43 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 27262 invoked from network); 12 Jun 2003 17:31:43 -0000 From: Ned Ludd Reply-To: solar@gentoo.org To: gentoo-dev@gentoo.org In-Reply-To: <20030612093735.GA29913@cherenkov.orbis-terrarum.net> References: <20030612092003.GA4707@tompayne.org> <20030612093735.GA29913@cherenkov.orbis-terrarum.net> Content-Type: text/plain Organization: Gentoo Linux (Hardened) Message-Id: <1055438723.12959.289.camel@simple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2- Date: 12 Jun 2003 13:25:23 -0400 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] apache eclass X-Archives-Salt: 94e8722c-aea5-4238-8793-0ea49b50998e X-Archives-Hash: cb9395e0d7fa8684c884292193068662 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 Gentoo Linux (Hardened) -- gentoo-dev@gentoo.org mailing list