Date: Wed, 11 Jun 1997 21:16:57 +0200 From: Gerhard Sittig <G.Sittig@abo.freiepresse.de> To: edward.ing@utoronto.ca Cc: FreeBSD-questions <FreeBSD-Questions@FreeBSD.ORG> Subject: Re: User server daemons listening on SOCKETS? Message-ID: <339EF9A9.4BAB@abo.freiepresse.de> References: <339DF49E.5AC6@utoronto.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
edward.ing@utoronto.ca wrote: > > Is it possible to programme a server daemon that listens on a Socket > and then spawns a new connection process to provide the service to > run under a users environment rather than the root environment. > Sounds like it could be done with a single line in inetd.conf ? As mentioned before by the other guy, you might want to contact your provider on that. > For example I was going to write a Java server to run a user account and > distribute a client so that users of the client can connact my > server over the internet. I don't have root access to unix box on the > 'Net so I would like to resort to running a service from my user > account. If the inetd meta demon (or it's admin :) won't give you what you want, you may do it yourself by select(2)ing between a contacting port and the service ports where connections are serviced. But the contacting port has to be known to your clients. > Is this easily accomplished? Or will unix kernels not allow this > kind of "sockets-on-user-demand" processes? > > If I can, how can I write a routine to automatically determine which > ports are free so my server will not spawn a process which will uses a > port that another daemon on the host is using? I don't know if I'm completely wrong, but as far as I can remember RPC connections are established via the portmapper (UDP/TCP port 111) and get any free socket available. And since the program ID is integer there's even more room than in the 16 bit ports (although only one quarter is reserved for "general purpose and testing"). Any user space program can register with the portmapper and any client may establish a connection (as long as the prog's ID is known -- see above). And you may even scan remote hosts by means of rpcinfo(1/8 ?). RPC has function numbers as a "jump table index" and in addition a version counter -- so you even may service requests at the same server and in parallel even when you change / extend the interface definition. > What security loop-holes might there be? You might want to use a TCP wrapper to allow / deny several hosts / users / ports. And RPC connections have connection info structure to learn where the request comes from. There is secure RPC, too -- but I didn't play with it yet. > edward.ing@utoronto.ca Hope this helps. -- virtually yours -- G.Sittig@abo.FreiePresse.DE If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?339EF9A9.4BAB>