On Tue, 17 Apr 2007, Paul Singleton wrote:
David Smith wrote:
Ahhh the joy of *nix operating systems. Way back in the distant past of
unix systems, someone decided it was a bad idea to allow any user on the
system to bind to the well known low ports (1 - 1024) where officially
sanctioned services (POP, SMTP, FTP, etc., ...) should be. A great idea
except it also required the services to be running as a privileged user to
gain access. For a lot of reasons, services should run with the least
privilege.
This kludge was forgiveable on "multi-user" systems (anyone remember
them?) but makes things worse on secure servers; unfortunately you
seem to have to recompile the kernel to switch it off...
A couple of the most common solutions to this problem are:
1. Start tomcat using jsvc. You can get it from the commons-daemon project
at http://jakarta.apache.org/commons/daemon
2. Run tomcat on a higher port like 8443 and attempt to use iptables to
divert the traffic intended for 443 to tomcat. I'm a bit dubious on if
this will work with an SSL connection. You can try it if you like.
It works as well for HTTPS as it does for HTTP (i.e. fine) but you may
nevertheless prefer to avoid configuring port redirection into iptables.
My vote is for 1. It's easy and tomcat can act as a well behaved,
respectable service running with minimum privilege while still capturing a
"privileged" port.
I opted for 2 (have used this in production a coupla years now) as
it doesn't involve any software you wouldn't have to use anyway (if
someone discovers a security vulnerability in jsvc tomorrow I shall
be smugly smiling) but realistically there's nothing in it and the
choice is yours...
I'm inclined to go for 1 if it is simpler. It sounds like it is simpler.
However, I'm curious; do you know what kernel flag needs to be recompiled
in order to switch this off?
Faheem.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
