Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-tm-dev] Dstore to use privileged ports for serverPortRange
Title: Dstore to use privileged ports for serverPortRange
Do you want the dstore SERVER or the DAEMON to listen on the privileged port?
 
What if you use an external program to listen on the privileged port and relay its communication?
 
In the simplest case, you could use netcat (nc), a little bit more advanced is socat; or, you
have an sshd daemon listen and open ssh tunnels throug it; or, you have a SOCKS proxy
running and relay its ports.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Schmidt, Denise
Sent: Montag, 06. Juli 2009 23:02
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: [dsdp-tm-dev] Dstore to use privileged ports for serverPortRange

We are interested in modifying Dstore to allow the serverPortRange to use privileged ports (<1024).  I had posted a newsgroup question about this and now we’re looking at how we could make changes for this.

We were first looking at starting the org.eclipse.dstore.core.server.Server method as root and then calling the native Unix setuid to change the effective user ID to that of the client.  But after thinking more about it, there is the possibility that the user could execute something that would setuid the process back to root and then they would have authority on the remote system they should not have.

So now we are looking at possibly splitting the server functionality into separate processes, one that runs as root and communicates over the network and one that runs as the client user ID and does all the “real” work on the remote system.  The 2 processes would have to communicate data between them.  I’ve been looking over the Dstore source code to see how easy that separation might be. 

Does this solution sound reasonable?  Is there another, possibly better solution we haven’t thought of?

Any suggestions or things we should consider while tackling this are appreciated.  We’d like to work this out so that we could contribute our changes back.

Thanks.

Denise Schmidt

Back to the top