Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

So I have a RedHat 5 box that I'm wanting to run an application that I wrote that implements SLP. SLP uses port 427 for answering service queries. My understanding is that ports below 1024 are "privileged" and thus cannot be bound to by anyone that's not root. I cannot run this application as root as it is launched via tomcat.

One creative solution I really like was simply writing an iptables rule to route the privileged port to a non-privileged. In my proof of concept tests, this works wonderfully. Unfortunately, it would be greatly (and understandably) desired by the powers if my application did not require screwing around with iptables upon installation.

So I heard a rumor and cannot find anything to verify this that there was some sort of command or parameter that could be set to make any port I want be non-privileged. Is this true? If so, how is this done? Thanks!

UPDATE

So I saw this post on Stack Overflow: http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l It looks like he used something called capabilities. The problem with this is it seems to require kernel 2.6.24+, but I only have access to kernel 2.6.18. Is there a way to set capabilities on a 2.6.18 box?

share|improve this question

2 Answers 2

You're essentially asking the same thing as this:

http://stackoverflow.com/questions/5544713/starting-tomcat-on-port-80-on-centos-release-5-5-final

So, use jsvc.

share|improve this answer
    
Thanks for the response, but am I asking the same question? My understanding is that jsvc will start tomcat as root and then drop down to a normal user. Let's assume that I start Tomcat this way. I still couldn't open up port 427, could I? By the time Tomcat starts my war, I'd be a regular user, wouldn't I? –  Jason Thompson Apr 12 '12 at 17:40
    
I haven't used jsvc, but if it can bind to port 80 and then drop privs, you can certainly bind to port 427 and drop privs. That's actually the "standard" way of dealing with privileged ports running on a non-root process: you bind to the low port as root and then drop privileges (or you have a master process running as root, which will spawn child workers that do the actual work). –  cjc Apr 12 '12 at 17:58
    
An alternative would be to do the "standard" thing with serving from Tomcat, which is to use a proxy like Apache (and have it handle static content, etc). I'm not sure about the case of your application, but Apache can certainly bind to 427 and proxy over to your Tomcat running on a high port. –  cjc Apr 12 '12 at 18:00
    
I'm not for sure, but the proxying may not work since I'm trying to listen for and send out multicast UDP datagrams, not TCP HTTP packets. But it may be worth looking into. –  Jason Thompson Apr 12 '12 at 19:44

A bandaid approach would be to listen non a non-privileged port, then redirect with xinetd from the privileged port.

$ grep bandaid /etc/services
bandaid         190/tcp                       # bandaid

$ cat /etc/xinetd.d/bandaid
service bandaid
{
    disable = no
    bind = 10.0.0.45
    socket_type = stream
    protocol = tcp
    wait = no
    user = nobody
    redirect = localhost 8888
}

This is an awful idea IMO, but sometimes you don't have any other options.

share|improve this answer
    
I'm intrigued, Jodie. Why is this an awful idea? –  Jason Thompson Apr 12 '12 at 20:12
    
It's that forwarding the TCP connection is a bandaid. In a better solution you would run the app itself as a xinetd service on that port. xinetd unprivileged port question –  Jodie C Apr 12 '12 at 23:16
    
After doing some research, it appears that xinetd does not support redirecting a UDP port. :( SLP uses broadcast datagrams. So I cannot use the xinetd solution. That being said, this looks like it would be great solution for other situations. –  Jason Thompson Apr 13 '12 at 13:25
    
Could you just run the software as a xinetd service? –  Jodie C Apr 13 '12 at 13:34
    
No. It's part of a java web archive (war) as a ServletContextListener. When Tomcat starts the war, the listener then kicks off and binds to the port. My gut tells me that my boss would not want to tear this process away from the war. –  Jason Thompson Apr 13 '12 at 15:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.