[
https://jira.jboss.org/jira/browse/JBAS-6926?page=com.atlassian.jira.plug...
]
David Lloyd commented on JBAS-6926:
-----------------------------------
I would personally never condone running any Java application as root, even for a moment.
I don't think including something like this in the core platform is a good idea, no
matter what kind of warnings are attached to it. If you're looking at a JNI solution
anyway, you might as well go with my solution #2 (in the description) which is to use a
root process to do the binding for you and pass it to the main program via AF_UNIX.
Though solution #3 above is the best of all, if one can manage it. One could implement it
by way of a simple program which runs as root, sets the capability, changes UID, and then
execs the Java program as an unprivileged user with the ability to bind privileged ports.
Run JBoss on privileged port (80) without running as root
---------------------------------------------------------
Key: JBAS-6926
URL:
https://jira.jboss.org/jira/browse/JBAS-6926
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: System service, Web (Tomcat) service
Reporter: Brad Maxwell
Assignee: Dimitris Andreadis
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira