|Re: [dsdp-tm-dev] Dstore to use privileged ports for serverPortRange|
I don't have experience doing the sort of thing your intending to do so I'm not sure how much help I can provide here. One product has used dstore to run the daemon and it's servers in a single admin process. In that scenario, the security is handled via a custom ISystemService in SecuredThread. The host system has a unique security model that might not be replicable in other environments.
I suppose if you keep the server and daemon as separate you might be able to pipe the appropriate daemon socket traffic to files that can be read/written by a server running in the client user's environment. Note that this would require changes to, not only the server code, but also the client DataStore and connector sevice code and I would expect there would be required API changes.
Phone: 905-413-3902 , T/L: 969-3902
"Schmidt, Denise" <denise.schmidt@xxxxxxxx>
Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxx
06/07/2009 05:02 PM
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.
dsdp-tm-dev mailing list
Back to the top