Many customers want to run JBoss Web on port 80 without running JBoss as root for security reasons. This is usually achieved by fronting JBoss with Apache & using mod_jk to proxy to JBoss or doing NAT on the machine. It would be nice if JBoss could be started as root but have configuration that would change to a non-root user after it has opened the ports such as port 80 for jboss-web, such as Apache and other app servers do. Some customers run on several different operating systems and would like to do this at the JBoss level so they don't have to configure each machine differently.

Below are some possibilities to achieve this:

Changing UID is something that would have to be done via JNI (in other words, platform-specific compiled libraries - possibly more than one per platform [I'm thinking of hybrid 32/64-bit platforms]). That said I could envision a couple possible solutions for UNIX platforms (all would require development work however):

Solution 1
----------

• JBAS starts up by running Main
• Main notices a special configuration option to bind certain ports upfront, stores those bound sockets for later
• Main notices a special configuration option to switch UID, uses the JNI stub to do so
• Commence normal bootstrap
• JBossWeb (or any other network component) has a provision to re-use pre-bound sockets
• On redeploy or connector undeploy, those sockets had better not be closed or else they won't be able to be re-bound

Solution 2
----------

• A separate "binder" program is written (in C) which creates a AF_UNIX socket with restricted permissions and runs as root
• JBAS starts up, runs through bootstrap normally as a non-priv user
• Rather than creating a ServerSocket, JBAS uses a JNI stub to connect to the AF_UNIX socket, and send a request to bind a privileged socket address
• The "binder" program binds the address and sends the file descriptor back over the AF_UNIX socket, and closes its local copy of the server socket
• JBAS reads that server socket back off the AF_UNIX socket
  (note that this is arguably slightly more elegant as a custom ServerSocketFactory could do this transparently for non-NIO usages)

Solution 3 (Linux only)
-----------------------

• Run JBAS with CAP_NET_BIND_SERVICE

Note that these solutions all rely on platform-specific mechanisms, because it's a platform-specific problem. The best we can do is come up with a way to distribute the JNI guts in such a way that it doesn't look like a platform-specific solution.

• DML