1 |
On Saturday 15 December 2007, Randy Barlow wrote: |
2 |
|
3 |
> It's not too hard to start a separate instance of apache. You just |
4 |
> copy /etc/init.d/apache2 to, say, /etc/init.d/backuppcApache2. |
5 |
> Likewise copy the /etc/conf.d scripts, and change in the backuppc one |
6 |
> the reference to the httpd.conf to, say, /etc/BackupPC/httpd.conf. |
7 |
> Then, in that .conf file, make sure that you change the things to be |
8 |
> suitable for BackupPC (in particular, get rid of the lines that |
9 |
> include *.conf's from certain directories because these will cause |
10 |
> apache to try and use the same PID! Make sure you specify a new PID |
11 |
> file, among a few other related things) I really don't think the |
12 |
> ebuild should let you use the same instance of apache that |
13 |
> /etc/init.d/apache2 starts, because this would be a security risk. |
14 |
|
15 |
Well, if you want the setuid behavior (vs. having a separate instance), |
16 |
you have to use the already-existing apache. |
17 |
|
18 |
> For example, I use BackupPC to back up three machines, in their |
19 |
> entirety. That means that backuppc has the rights to change any files |
20 |
> on those three machines. I've also got a webserver running, open to |
21 |
> the internet, on my backuppc machine. If people on the internet can |
22 |
> access backuppc, they can pretty much access all three of those other |
23 |
> machines. But if I run on port 8080, and have that port blocked by a |
24 |
> firewall, this is no longer a concern. |
25 |
|
26 |
Ideally, the box running backuppc does not offer public services and thus |
27 |
should not be exposed to the Internet, so I think that the configuration |
28 |
should not be thought as if it were. |
29 |
Rather, I'd assume that the backuppc box is on the trusted internal lan, |
30 |
with no direct exposure to internet, and configure accordingly (and see |
31 |
below). |
32 |
|
33 |
> The other option is to install password protection by default, but |
34 |
> then you have to have competent users who can change the httpd |
35 |
> passwords. I suppose you could write this as an instruction at the |
36 |
> end of the ebuild. But, are htaccess passwords sent in plaintext? If |
37 |
> so, that's also a major security risk. |
38 |
|
39 |
If you use plain text authentication, yes they are sent as clear text. If |
40 |
you use digest authentication, they are not cleartext but are very |
41 |
easily decoded. Again, the backuppc box is supposed to be inside the |
42 |
trusted lan and not exposed to public internet access. |
43 |
AFAICT, the ebuilds that install files into apache documentroot do not |
44 |
concern themselves with authentication (if nothing else because apache |
45 |
supports zillions of authentication methods, so what the user wants |
46 |
cannot be anticipated), thus apache access control configuration should |
47 |
imho be left out of the ebuild and performed as a subsequent step by the |
48 |
administrator (in some cases it should not even be needed, eg if the |
49 |
only user is the administrator). |
50 |
-- |
51 |
gentoo-user@g.o mailing list |