Restricting host accesses

[William.Smargiassi@smed.com]

Yeah, sure for things like telnetd and ftpd which run out of inetd and will
spawn a new copy for each new connection anyways, you would use tcpd
(TCP-wrapper the program). But that wouldn't work well with a VNC server
which would not fork off a new copy, but instead stay running, then when a
client leaves just sit there waiting for a new client connection. The
second client to hit that server would not have TCP-wrapper's protection.
Running VNC out of inetd prevents you from using the whole mobility aspect
of VNC you kill the server to exit the client, or does nothing if you just
kill the client, because of the second client problem... Or maybe I just
don't know TCP wrapper well enough. :)

Daemon-mode servers (which VNC more closely resembles) have different ways
of handling this. Some like ssh and samba (when run that way, it can also
run out of inetd) handle it themselves, some link in the TCP wrapper
library, and some like sendmail do either, depending on your requirements.

Maybe TCP wrapper linked in is the way to go here.

bill




joel "at" exc.com (Dr. Joel M. Hoffman) on 04/27/98 09:05:00

To:   nick "at" nexnix.co.uk
cc:   vnc-list "at" orl.co.uk (bcc: William Smargiassi/SMS)
Subject:  Restricting host accesses




>       Anybody working on (or thinking of) restricting host access by IP
addre
>Specifically for the Windows ports - I can manage the Unix side OK as is.
>Hein Roehrig <hein "at" acm.org> made some inroads on this, but he was only
>interested in restricting to localhost - I would like more flexibility.
>Alas as a non-programmer my C++ efforts are laughable........

I think putting IP access controls inside of VNC is the wrong way to
go.  Better to use a separate filter program.  This is standard
practice under Unix.  Surely something similar exists for Win95.

-Joel
(joel "at" exc.com)