Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Etaoin Shrdlu
On Saturday 15 December 2007, Randy Barlow wrote:

> It's not too hard to start a separate instance of apache.  You just
> copy /etc/init.d/apache2 to, say, /etc/init.d/backuppcApache2. 
> Likewise copy the /etc/conf.d scripts, and change in the backuppc one
> the reference to the httpd.conf to, say, /etc/BackupPC/httpd.conf. 
> Then, in that .conf file, make sure that you change the things to be
> suitable for BackupPC (in particular, get rid of the lines that
> include *.conf's from certain directories because these will cause
> apache to try and use the same PID! Make sure you specify a new PID
> file, among a few other related things) I really don't think the
> ebuild should let you use the same instance of apache that
> /etc/init.d/apache2 starts, because this would be a security risk.

Well, if you want the setuid behavior (vs. having a separate instance), 
you have to use the already-existing apache.

> For example, I use BackupPC to back up three machines, in their
> entirety.  That means that backuppc has the rights to change any files
> on those three machines.  I've also got a webserver running, open to
> the internet, on my backuppc machine.  If people on the internet can
> access backuppc, they can pretty much access all three of those other
> machines. But if I run on port 8080, and have that port blocked by a
> firewall, this is no longer a concern.

Ideally, the box running backuppc does not offer public services and thus 
should not be exposed to the Internet, so I think that the configuration 
should not be thought as if it were. 
Rather, I'd assume that the backuppc box is on the trusted internal lan, 
with no direct exposure to internet, and configure accordingly (and see 
below). 

> The other option is to install password protection by default, but
> then you have to have competent users who can change the httpd
> passwords.  I suppose you could write this as an instruction at the
> end of the ebuild. But, are htaccess passwords sent in plaintext?  If
> so, that's also a major security risk.

If you use plain text authentication, yes they are sent as clear text. If 
you use digest authentication, they are not cleartext but are very 
easily decoded. Again, the backuppc box is supposed to be inside the 
trusted lan and not exposed to public internet access.
AFAICT, the ebuilds that install files into apache documentroot do not 
concern themselves with authentication (if nothing else because apache 
supports zillions of authentication methods, so what the user wants 
cannot be anticipated), thus apache access control configuration should 
imho be left out of the ebuild and performed as a subsequent step by the 
administrator (in some cases it should not even be needed, eg if the 
only user is the administrator).
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Randy Barlow
Etaoin Shrdlu wrote:
> (btw, do gentoo initscripts 
> support starting multiple instances of a daemon, perhaps under different 
> users and using different parameters? I'd not bet on it, but I may be 
> wrong. If it's not supported, waiting for baselayout to support this may 
> take a long time, so it would be better to release the easier suid 
> version in the meanwhile.)

It's not too hard to start a separate instance of apache.  You just copy
/etc/init.d/apache2 to, say, /etc/init.d/backuppcApache2.  Likewise copy
the /etc/conf.d scripts, and change in the backuppc one the reference to
the httpd.conf to, say, /etc/BackupPC/httpd.conf.  Then, in that .conf
file, make sure that you change the things to be suitable for BackupPC
(in particular, get rid of the lines that include *.conf's from certain
directories because these will cause apache to try and use the same PID!
 Make sure you specify a new PID file, among a few other related things)
 I really don't think the ebuild should let you use the same instance of
apache that /etc/init.d/apache2 starts, because this would be a security
risk.  For example, I use BackupPC to back up three machines, in their
entirety.  That means that backuppc has the rights to change any files
on those three machines.  I've also got a webserver running, open to the
internet, on my backuppc machine.  If people on the internet can access
backuppc, they can pretty much access all three of those other machines.
 But if I run on port 8080, and have that port blocked by a firewall,
this is no longer a concern.

The other option is to install password protection by default, but then
you have to have competent users who can change the httpd passwords.  I
suppose you could write this as an instruction at the end of the ebuild.
 But, are htaccess passwords sent in plaintext?  If so, that's also a
major security risk.

-- 
Randy Barlow
http://electronsweatshop.com
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Etaoin Shrdlu
On Saturday 15 December 2007, Randy Barlow wrote:

> Yeah, that's the kinds of differences of opinion that are in the bug
> report, which is part of what makes this a more difficult ebuild to
> write.  Things like libraries are really easy because it's just a
> configure make make install, but here you have a lot of configuration
> files and differences of opinion.  I was thinking that a USE variable
> could be in order here, to support suid and a separate apache
> instance. Perhaps the variable could be suid?

First, my opinion is that BackupPC, while being a wonderful application, 
should be split in two parts (by upstream): the daemon, and the web 
interface, so that they don't have to run on the same machine. Last time 
I checked, this was not supported, even if the config file seemed to 
allow for such a config. If this was the architecture, then it could be 
split into two distinct ebuilds, like eg zabbix or other apps.

That said, and things being the way they are now, I'd make the suid 
behavior the default, since it requires less changes in a running system 
(a perl reemerge at most - assuming of course apache is already 
installed). If the user wants the separate apache instance, then he can 
set, say, USE=private-apache to get it. (btw, do gentoo initscripts 
support starting multiple instances of a daemon, perhaps under different 
users and using different parameters? I'd not bet on it, but I may be 
wrong. If it's not supported, waiting for baselayout to support this may 
take a long time, so it would be better to release the easier suid 
version in the meanwhile.)

But again, there might be better arguments for doing the opposite. I'll 
take a look at the b.g.o. page where the ebuild is discussed (last time 
I checked was long ago, and things have surely evolved by now).
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Randy Barlow
Etaoin Shrdlu wrote:
> Ah ok, I just thought it would be easier, to get things going and catch 
> up with upstream, to release an ebuild that only supports the suid mode 
> of operation, and then, taking the necessary time, improve it in future 
> releases, rather than supporting all the features right from the 
> beginning.
> 
> But of course this is just my personal opinion.

Yeah, that's the kinds of differences of opinion that are in the bug
report, which is part of what makes this a more difficult ebuild to
write.  Things like libraries are really easy because it's just a
configure make make install, but here you have a lot of configuration
files and differences of opinion.  I was thinking that a USE variable
could be in order here, to support suid and a separate apache instance.
 Perhaps the variable could be suid?

-- 
Randy Barlow
http://electronsweatshop.com
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Etaoin Shrdlu
On Saturday 15 December 2007, Randy Barlow wrote:

> Yes, I am aware of that.  The BackupPC ebuild should support either
> way, as there is a speedup of about 15x (according to the BackupPC
> author) when running the webserver as user backuppc.  There should be
> a USE variable controlling this.  Also, it is wise to not put backuppc
> on the same instance of apache so that it can run on a non-standard
> port.  The ebuild by default would not install any password control to
> backuppc, and so the web interface would be open.

Ah ok, I just thought it would be easier, to get things going and catch 
up with upstream, to release an ebuild that only supports the suid mode 
of operation, and then, taking the necessary time, improve it in future 
releases, rather than supporting all the features right from the 
beginning.

But of course this is just my personal opinion.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Randy Barlow
Etaoin Shrdlu wrote:
> (Apologies if this has already been mentioned)
> Another (maybe less intrusive, although slightly less efficient) option 
> is to install the BackupPC_Admin CGI as setuid so that it runs as user 
> backuppc (this is how I run BackupPC-2.1.2-r1). This does not require a 
> different instance of apache, nor it requires to use mod_perl. It does, 
> however, require USE=perlsuid, but this is already supported by gentoo.

Yes, I am aware of that.  The BackupPC ebuild should support either way,
as there is a speedup of about 15x (according to the BackupPC author)
when running the webserver as user backuppc.  There should be a USE
variable controlling this.  Also, it is wise to not put backuppc on the
same instance of apache so that it can run on a non-standard port.  The
ebuild by default would not install any password control to backuppc,
and so the web interface would be open.

-- 
Randy Barlow
http://electronsweatshop.com
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Etaoin Shrdlu
On Saturday 15 December 2007, Randy Barlow wrote:

> One of the challenging things about the BackupPC ebuild is that the
> program needs to be configured to work with its own instance of apache
> (run as user backuppc), and I think none of the ebuild contributors
> are all too sure of the standard "Gentoo" way of doing this.  I'd be
> happy to try and make an ebuild that is a good compromise of the ideas
> listed in the bug.

(Apologies if this has already been mentioned)
Another (maybe less intrusive, although slightly less efficient) option 
is to install the BackupPC_Admin CGI as setuid so that it runs as user 
backuppc (this is how I run BackupPC-2.1.2-r1). This does not require a 
different instance of apache, nor it requires to use mod_perl. It does, 
however, require USE=perlsuid, but this is already supported by gentoo.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Randy Barlow
Hans de Graaff wrote:
> A possible solution would be for you (or someone) to become a proxy 
> maintainer, meaning that you'd get the bug reports and provide new 
> ebuilds, and a developer (most likely someone from the backup herd) would 
> review it and put it in the tree.

Hi Hans, thanks for the reply!  Being a student, I will soon have some
time to help out, so this might be a good thing for me to do.  How does
one become a proxy maintainer?  Should I just write [EMAIL PROTECTED]

One of the challenging things about the BackupPC ebuild is that the
program needs to be configured to work with its own instance of apache
(run as user backuppc), and I think none of the ebuild contributors are
all too sure of the standard "Gentoo" way of doing this.  I'd be happy
to try and make an ebuild that is a good compromise of the ideas listed
in the bug.

-- 
Randy Barlow
http://electronsweatshop.com
-- 
[EMAIL PROTECTED] mailing list



[gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Hans de Graaff
On Fri, 14 Dec 2007 21:07:53 -0500, Randy Barlow wrote:

> 7v5w7go9ub0o wrote:
>> My concerns with this, other than my abilities, are:
> 
>> 1. Showing proper respect to the guy who pioneered the effort to date,
>> and who may simply be out of town. (This disrespect would be alleviated
>> if there was an official policy encouraging "volunteer ebuilds".)
> 
> It's not disrespectful, IMO, to do something that you don't see getting
> done.  Especially since it's less work for another guy.  I wouldn't
> worry about that point.

As a developer I agree with that point. It's always better to get bug 
reports for version bumps or problems that have patches attached to them, 
or even a simple note saying that you copied the ebuild to the new 
version and things work fine.

> This can happen.  I've submitted ebuilds for backuppc-3.0.0, and so have
> many other people.  In fact, the bug for it has several ebuilds that
> have been submitted but haven't made it into the official tree.  I think
> that particular bug report might not be getting attention from the right
> people or something.  That doesn't mean it isn't worth doing though,
> because people can still use the ebuild from the bug report.  Ideally, a
> dev would see that, check it out for correctness, and add it to ~arch.

I guess you are talking about https://bugs.gentoo.org/show_bug.cgi?
id=141018 ? It's assigned to maintainer-needed (ie, it is in the tree, 
but currently no developer is maintaining it). The original maintainer 
recently retired, so it is now in some sort of limbo. In this case the 
fallback would be the backup herd (who are listed on the bug), but I know 
that these folks are understaffed. As you can tell from this we are 
always looking for more developers.

> Does anybody know how to call attention to a bug report that doesn't
> seem to have any devs paying attention to it?  I think BackupPC is a
> fine product, and would like to see it in the tree for others to use.
> I'm using my own ebuild successfully, as are many of the fine folks who
> have contributed on that bug report.  I'd just like my and others'
> efforts to be something that benefits more of the Gentoo community :)

A possible solution would be for you (or someone) to become a proxy 
maintainer, meaning that you'd get the bug reports and provide new 
ebuilds, and a developer (most likely someone from the backup herd) would 
review it and put it in the tree. 

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list