Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

How do I use port 80 as a non root user?

On Unix based systems, port 80 is protected and can usually only be opened by the superuser root. As it is not desirable to run the server as root (for
security reasons), the solution options are as follows:

  • Start Jetty as the root user, and use Jetty's setuid mechanism to switch to a non-root user after startup.
    or
  • Configure the server to run as a normal user on port 8080 (or some other non protected port).Then, configure the operating system to redirect port 80 to 8080 using ipchains, iptables, ipfw or a similar mechanism.

The latter has traditionally been the solution, however Jetty 6.1 has added the new setuid feature.

If you are using Solaris 10, you may not need to use this feature, as Solaris provides a User Rights Management framework that can permit users and processes superuser-like abilities. Please refer to the Solaris documentation for more information.

Using Jetty's setuid (and setumask) feature

Create a jetty config file like so:

Where you replace:

  • UMASK with the umask setting you want the process to have, or optionally remove this line if you don't want to change this at runtime
  • USERID with the id of the user you want the process to execute as once the ports have been opened.

    Hint

    Icon

    For your convenience, you'll find one of these ready made in the $jetty.home/extras/setuid/etc/jetty-setuid.xml.

    Then, you need to build the setuid feature for your operating system, as it requires native libraries. Go to the $jetty.home/extras/setuid directory and follow the instructions in the README.txt file, summarized here as:
    Where:
  • $JDK_HOME is same as $JAVA_HOME
  • linux should be replaced by the name of your operating system.

    On Solaris

    Icon

    Leave out the -shared argument.

    Then to run jetty as the root user, switching to the userid of your choice (and setting the umask of your choice if you chose to do that) you do:

    Note!

    Icon

    You must ensure that the etc/jetty-setuid.xml file is first in the list of config files.

Using ipchains

On some Linux systems the ipchains REDIRECT mechanism can be used to redirect from one port to another inside the kernel:

This basically means, "Insert into the kernel's packet filtering the following as the first rule to check on incoming packets: If the protocol is TCP and the destination port is 80, redirect the packet to port 8080." Your kernel must be compiled with support for ipchains. (virtually all stock kernels are.) You must have the "ipchains" command-line utility installed. (On RedHat the package is aptly named "ipchains".) You can run this command at any time, preferably just once since it inserts another copy of the rule every time you run it.

Once this rule is set up, a Linux 2.2 kernel will redirect all data addressed to port 80 to a server such as Jetty running on port 8080.This includes all RedHat 6.x distros. Linux 2.4 kernels, e.g. RedHat 7.1+, have a similar "iptables" facility.

Using iptables

You need to add something like the following to the startup scripts or your firewall rules:

The underlying model of iptables is different to that of ipchains so the forwarding normally only happens to packets originating off-box. You will also need to allow incoming packets to port 8080 if you use iptables as a local firewall.

Be careful to place rules like this one early in your "input" chain. Such rules must precede any rule that would accept the packet, otherwise the redirection won't occur. You can insert as many rules as needed if your server needs to listen on multiple ports, as for HTTPS.

Using usermod

On Solaris 10 (maybe earlier versions too) the OS allows you to grant privileged ports binding to "normal" users:

Now the myself user will be able to bind to port 80.

Using xinetd

With modern Linux flavours, inetd has a newer, better big brother xinetd. I'm not going to get into detail about it, there are plenty of man pages etc out there.

But the point is that you can use xinetd to redirect network traffic, and all you need is a text editor.

xinetd is driven by text files. Now there's 2 ways to give xinetd instructions:

  1. Add a new service to etc/xinetd.conf
  2. Add a new file to the directory etc/xinetd.d

Take your pick, the format is the same, if you have a look at the file/directory, you will get the picture.

The following entry will redirect all inward tcp traffic on port 80 to port 8888 on the local machine. Of course you can
redirect to other machines for gimp proxying:

Points to Note

  • Space on either side of the '=' or it is ignored.
  • type = UNLISTED means that the name of the service does not have to be in /etc/services, but you have to specify port and protocol. If you want to do use an existing service name, e.g. http:
    Have a browse in /etc/services and it will all become clear.
  • Logging may present certain security problems, you might want to leave that out.
  • RHEL5 for some reason doesn't contain xinetd by default for reasons best known to themselves. yum install xinetd will fix that.

Xinetd is a hugely powerful and configurable system so expect to do some reading.

  • No labels

7 Comments

  1. On Solaris, the option -shared, could led to the following error:

    Just remove that option and the library will be compiled.

  2. Thanks Claudio, I've updated the wiki instructions with this.

  3. I tried compiling libsetuid.so with your compiling command, but got a linking error, with 'main' being an undefined symbol.  The solution is to add a -c to the command!

  4. One other thing: in the example, it says that you want etc/jetty-setuid.xml to be first--but when i tried that, i got permission denied errors.  When i put it AFTER jetty.xml, everything as fine.

  5. Normally the command-line arguments to Jetty are the names of xml files that create Server instances. The jetty-setuid.xml file creates a subclass of Server: org.mortbay.setuid.SetUIDServer. Assuming none of the Servers do anything strange, like starting themselves, Jetty starts Servers in the order they are passed to it on the command line. The SetUIDServer class doesn't actually modify the UID until it starts.

    Therefore, if you have a jetty.xml that creates a Server that must start as root because it listens on port 80, then you will want to list it before jetty-setuid.xml on the command line.

    By the way, in addition to being able to listen on port 80, running Jetty initially as root is also useful for reading in property files containing keys and passwords, since then you can make the files only readable by root.

  6. Another way to have Jetty open port 80 but then change users would be to use commons-daemon (http://jakarta.apache.org/commons/daemon/). Commons-daemon is what Tomcat uses to run as a daemon. To use it with Jetty, you would probably write a small application that embeds your Jetty server, and your application would implement the org.apache.commons.daemon.Daemon interface, which has init() and start() methods. Commons-daemon calls init() with superuser privileges, and then start() with the downgraded privileges. Since Jetty's Server.start() requires superuser privileges to open port 80 (I think), you would call it from your init() method. (This is not ideal, since the Server starts accepting connections while still running as superuser, but I think that's a problem even with Jetty's "setuid" feature.) Commons-daemon includes an init script that can be used in an "init.d"-style directory.

    There are some advantages to using commons-daemon instead of the new "setuid" feature:

    • It can be used with any version of Jetty
    • It lets you keep your container pure java (commons-daemon has a native component, but it calls Jetty..not the other way around)
    • You don't have to worry about the order that Jetty loads config files
    • Commons-daemon will restart Jetty if it crashes (I don't know if that happens in the real world)

    The main disadvantage is that you would have to write a (small) wrapper application. Perhaps someday Jetty will come with such a wrapper.

  7. When using this feature, some JVM instrumentation like jps, jstat will not work, I found this unresolved bug

    # ./java -version
    java version "1.6.0_02"
    Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
    Java HotSpot(TM) Server VM (build 1.6.0_02-b05, mixed mode)
    
    # ps -ef|grep java
    webservd   555   916   0 01:49:26 pts/1       1:08 /opt/jdk1.6.0_02/bin/java -Xmx96m -Djava.library.path=lib/ext -Dfile.encoding=U
        root  6032   670   0 02:50:09 pts/1       0:00 grep java
    
    # id
    uid=0(root) gid=0(root)
    
    # ./jps -l
    6034 sun.tools.jps.Jps
    555 -- process information unavailable
    
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery