tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Why run tomcat as root
Date Sat, 07 Dec 2002 02:35:15 GMT

On Fri, 6 Dec 2002, Vy Ho wrote:

> Date: Fri, 06 Dec 2002 13:13:36 -0500 (EST)
> From: Vy Ho <>
> Reply-To: Tomcat Users List <>
> To: Tomcat Users List <>
> Subject: RE: Why run tomcat as root
> Well, assume you're right, then I and many developers have to live with
> this fact then.
> I would like to make myself clear abit though.  Whatever decision they
> made over 40 years about limiting the access to port 0-1024, I dont
> question, or ask to change, or agree upon or disagree with.  I just think
> if there is something they can do that what they try to protect would
> work, and the problem we face would be solved.  See the number of response
> to this topic obvious shows that there's some
> concern/issues/misunderstanding/inconvinience.  Whatever you call it.

Unix (and Linux) provide mechanisms to deal with this already, without
changing the root-only restriction for ports < 1024.

* There's a system call to change your user id (this is what
  Apache itself does to grab port 80 as root and then switch
  itself to a non-privileged user before actually doing anything
  else.)  Doing something like this for Tomcat is technically
  feasible, but will require a bit of native code and some tweaks
  to the way that the TCP connectors are started up.

* There's utilities like ipchains that can automatically forward
  port 80 connections to some other port (such as one that's not
  privileged), and optionally implement firewall type access controls
  as well.

* You can create a "chroot" environment that limits the scope of
  things the process can actually get to, even though it thinks it
  is running as root.

There's no need to change the root-only restriction to solve this
"problem".  Adequate mechanisms are already there to accomplish what you
need.  Use them.

> My feeling as a developer is that kernel develoeprs would make life
> better, whether it's a matter of convinient (without sacrafice security or
> whatever else).  Ofcourse, there's other priority that make no body care
> to this about this issues.  But that is another story.  I think this was
> asked enough to have a good talk about.  I also thought that this is a
> relative easy to change in the kernel (for the kernel dev. expert).  I
> also don't think it would be a security problem or backward compatable
> problem (since the admin must allow some users to use port 80 for it to
> work).
> About the work around terminology, whatever you call it, and I may use it
> wrongly, but I think it's a hassle to do other stuff just for this little
> thing.  You may think it's not a hassle, it's nothing you maysay.  Well,
> it's users' votes.  When there's enough on one side or another, there's
> maybe better reason to address it oneway or another (such as do nothing).
> About philosophy, and 40 years of thought.  I think you have a good point
> on the time and all that.  But time change.  Things now are different than
> before.  So, sometimes, changing is not that bad, and people/developers do
> that all the time.  That's how Linux improve every day.

Change should only happen when existing solutions don't work any more.
Change for change's sake is a waste of time.

That is not the case for this scenario, so I'd be amazed if your proposal
ever gained any traction.  Of course, it's really the Unix and Linux (and
Windows, because it follows a similar-but-different pattern) developers
that you'd need to make your arguments to.  There's nothing that Tomcat,
or Tomcat developers, can do to change this.

Therefore, I suggest anyone interested take any more discussion of whether
operating systems should be changed someplace else -- it's off topic for
TOMCAT-USER.  If you want Tomcat to support running directly on port 80
without being root, put your enhancement request in to the bug tracking

Better yet, attach patches that make the required changes to Tomcat to
implement this idea.  It'd get implemented a whole lot faster that way.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message