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>