Thanks.
It sounds like what you're asking for is for Perlbal to start as root
and then switch to another user, similarly to what Apache does.
The problem is that unlike Apache Perlbal runs in a single process, so
if it switched to another user after startup it would become impossible
to use management commands to dynamically change the listening ports at
runtime. However, I guess rebinding listen ports at runtime isn't done
that frequently. It'd presumably be possible to write a plugin to add a
new management command to change userid at runtime if someone was so
inclined.
For now, if your goal is to get Perlbal listening on port 443 while
having it not run as root, one option would be to use something like
netfilter or maybe xinetd to forward stuff on port 443 to a Perlbal
running on the loopback interface on a high port number.
Only you can define what is or is not 'acceptable risk'. Many people
run Perlbal in production environments as root and don't have any
problems. However, if your requirements are more stringent, then this
may of course be a problem for you.
At any rate, Perlbal runs as root and is not currently able to drop
privileges. We talked about it some but never got around to
implementing it. A patch would definitely be accepted.
--
Mark Smith / xb95
smi...@gmail.com