1 |
Aside from all DocumentRoot stuff I feel that one of the most important |
2 |
things that needs to be addressed by any apache.eclass is what version |
3 |
of apache are we using 1,2 when ~arch flags are set. I was reently very |
4 |
unhappy to find out that apache2 got installed on one of my production |
5 |
servers after doing an upgrade world when -apache2 was explicitly set |
6 |
and the box previously had apache1 installed. |
7 |
|
8 |
A FORCE_APACHE=1|2 option was mentioned the other day here on the ml, I |
9 |
support that idea fully. |
10 |
|
11 |
What I would like/hope to see is for carpaski to make the final decision |
12 |
if any sort of dynamic method should be used to gain the apache |
13 |
docroot,user,group, and other runtime settings. Then hopefully one of |
14 |
you (Brad Laue comes to mind as it looks like he was willing to step up |
15 |
to the plate) will parent the needed {apache,http}.eclass |
16 |
|
17 |
> > Have a look at http://bugs.gentoo.org/show_bug.cgi?id=20642 with regards to |
18 |
> > automatically determining DocumentRoot. |
19 |
> > Synopsis is that a simple grep breaks configurations that use virtual hosts. |
20 |
> > Reliably detecting the doc root on all possible installations is very hard |
21 |
> > indeed. |
22 |
|
23 |
Thus why the example code only extracted the very first case of |
24 |
DocumentRoot out of the conf and ensured there would be no extra |
25 |
whitespace/tabs something that a simple "grep | cut " can not address |
26 |
correctly. I also feel the logic I used is for the example code to get |
27 |
the docroot is sane (other than UPPER vs lower case, but that could be |
28 |
addressed by using grep -i). I suppose one could do more and add the |
29 |
extra step to ensure that the document root really does exists. |
30 |
[ ! -d "${DOCUMENT_ROOT}" ] && die "some clever error msg here" |
31 |
|
32 |
Note: I'm not 100% sure that we can die correctly from within an eclass |
33 |
|
34 |
> > After discussion with others, my recommendation is that the document root |
35 |
> > should always be /home/httpd/htdocs. You could allow this to be overridden |
36 |
> > with DOCUMENT_ROOT= in /etc/make.conf if you're feeling generous. |
37 |
|
38 |
This is what I would really like to see in the end result. |
39 |
|
40 |
> Actually, in a further discussion today in #gentoo-dev, we noted that |
41 |
> detected the DocumentRoot or allowing to be variable in any fashion |
42 |
> causes more serious problems with tbz2 binary tarballs. |
43 |
> For example: |
44 |
> DocumentRoot is /var/www |
45 |
> User builds a web application, which installs to /var/www. The tbz2 |
46 |
> contains files with that pathname component in them. |
47 |
> Now DocumentRoot gets change to /home/httpd/htdocs (any number of ways, |
48 |
> including emerging the binary package on a different system). |
49 |
> User tries to install the package, telling emerge to use the |
50 |
> pre-existing binary. |
51 |
> Package is extracted to /var/www, which is never looked at by the |
52 |
> webserver. |
53 |
|
54 |
I feel one of the really great things about gentoo is its flexiablity, |
55 |
users can build there systems exactly how they want when they want. |
56 |
Having such variables in an eclass that can be overridden by the enduser |
57 |
at compile time to me seems by far the best option for our users. I have |
58 |
faith that "most" of gentoo's users that would edit such an option would |
59 |
know what there doing in reguards to there own DocumentRoot. |
60 |
|
61 |
> |
62 |
> Because of this DocumentRoot must be totally static. |
63 |
> If we ever want DocumentRoot to be variable, somebody has a LOT of work |
64 |
> to do with apache config parsing. |
65 |
> |
66 |
> In cases where users want a different DocumentRoot, I would suggest that |
67 |
> the packages are all installed in a fixed location (not nessicarily even |
68 |
> in the DocumentRoot directory), and then the user can symlink them into |
69 |
> their own DocumentRoot. |
70 |
> A possible solution: |
71 |
> All webapps install to something NOT inside DocumentRoot. |
72 |
> 'ebuild /usr/portage/.../foo.ebuild config' sets up the application |
73 |
> (needed in most cases already) AND puts in a symlink to the |
74 |
> DocumentRoot. |
75 |
> This also makes it easier to support virtualhost configurations that all |
76 |
> have access to a common tool, and makes temporarily disabling an |
77 |
> application for security reasons much easier to do. |
78 |
|
79 |
For security reasons I see that as having both pros and cons. |
80 |
You addressed the pros, I will address the only con I can think of off |
81 |
the top of my head. This type of setup would require that FollowSymLinks |
82 |
must always be set which could potentionaly introduce new security holes |
83 |
depending on the app thats being installed. |
84 |
|
85 |
|
86 |
Another thing which was not addressed by the example eclass is what |
87 |
permissions should webapps install as. I notice a few ebuilds are making |
88 |
everything owned by apache.apache and are world readable. I like would |
89 |
suggest that when you (any dev) dont know what permissions to use try |
90 |
and make the files root owned apache readable and other non -rwx |
91 |
readable,executable,writeable |
92 |
(-rw-r----/0640) root.apache This would keep all users expect the apache |
93 |
user itself from reading misc the misc php,perl scripts which sometimes |
94 |
contain things like mysql passwords. Granted crafty local users could |
95 |
get around those permissions pretty easy to extract passwords but it |
96 |
would improve the overall security of installed files. And when a webapp |
97 |
says its needs to be mode 666 (laugh to yourself and try to make the |
98 |
file apache owned with 0600 or 0660) |
99 |
|
100 |
-- |
101 |
Ned Ludd <solar@g.o> |
102 |
Gentoo Linux (Hardened) |
103 |
|
104 |
|
105 |
-- |
106 |
gentoo-dev@g.o mailing list |