Have you looked at the jakarta commons-daemon?
http://jakarta.apache.org/commons/daemon/jsvc.html
I'm not sure how well it would work in your case but I've gotten it to
run tomcat as non-root user on linux bound to port 80.
-Herman
On Sat, 2004-09-11 at 13:45, randy calma repasa wrote:
I would like to thank everyone who have shared their suggestions,
experiences, document links, etc... to my problem at hand. Please allow
me to summarize:
1. Use ndd -set /dev/tcp tcp_smallest_nonpriv_port [ < 1024 ]. Ndd
however, does not allow the value to be below 1024 (whether from
runlevel 1 or runlevel 2) like Casper Dik said. I may have read
somewhere that there is a header file somewhere that allows us to define
this parameter value to be lower, i am looking for links or documents
that could point me to this file's location.
I was planning on closing the security hole left by lowering the
smallest non-privileged port with the tcp_extra_priv_ports_add paremeter
for every port < 1024; except for the port i want open for the java
application.
2. Setting the setuid bit (chmod 6751) on the application launcher
(a shell script actually which starts the java application) and then
chown(ing) the file to root. This left me with a licensing issue that
would require an abnormally long amount of time to resolve with the
application developers (at the moment it will not start unless the
licensing is changed or added for user root), plus the uncertainty of
not knowing whether the application can and should be run as root. The
application uses (and was developed for) an ordinary account to start
and run.
3. Setting the setuid bit on the application launcher and running
the script as root with the file owners environment variables. No dice.
I thought this would have the intended effect of temporarily gaining
root's all powerful blessing and allow the application to bind to my
target port. Silly me.
A little background for those suggesting port mapping/port forwarding:
The java application normally uses two ports for communication with
the clients: one for normal and one for encrypted traffic. Setting which
ports to use upon application startup is done using configuration files
at the application $HOME direcroty. For clients to be able to use the
application, they point to a URL hosted in the server (at port 80);
download the java client (which is automatic) and communicate with the
server application using the ports specified at configuration. The java
client shares the server application's port settings.
Ipf (or port forarding/port mapping tools) would provide an
excellent solution if the client's ports are independent from that of
the servers application's, however they are not.
The reason for the client's request to have the application use port
443 is that it is the only port they can open at the firewall to allow
the application's traffic. The server application is hosted at our
server, while they initially point to their browsers to application's
web launcher and then launch the java client from there. They have
denied requests for the application's ports to be allowed through the
firewall (call them finicky and paranoid, call me frustrated).
Right now i am still trying to find ways to solve the problem. I
will appreciate any and further suggestions that this list's experience
can lend me.
Thank you very much and best regards.
Randy
