Re: [Libvncserver-common] Relax setsockopt TCP_NODELAY to enable AF_UNIX sockets

[Johannes S. <Joh...@gm...>]

Hi,

On Wed, 29 Dec 2010, Karl J. Runge wrote:

> Although the need for non-TCP sockets for libvncserver is rare, they do 
> enable some interesting tunnelling schemes.  For example, when listening 
> on an AF_UNIX socket the connections are limited to processes that have 
> file system access to the socket.  Another example is that the 
> libvncserver inetdSock mode can be used for a raw stdio pipe (e.g. a ssh 
> tunnel with no need for a -L port redirection.)
> 
> These aren't possible now in libvncserver, but only for a trivial reason,
> in a couple of places libvncserver calls setsockopt(2) to set TCP_NODELAY,
> e.g:
> 
>       if (setsockopt(sock, IPPROTO_TCP, TCP_NODELAY,
>                      (char *)&one, sizeof(one)) < 0) {
>         rfbLogPerror("setsockopt failed");
>         close(sock);
>         return NULL;
>       }
> 
> and this will always fail for non AF_INET sockets.
> 
> I enclose a patch that alleviates this problem for people to have a look
> at to see if it is OK.  It simply reports the setsockopt failure as a
> warning and lets the connection continue (in rfbserver.c it also sets
> cl->host to "NON_AF_INET" instead of to a string with the IP address.)
> 
> Another (more compatible) option would be to call getsockopt() somehow
> to see if TCP_NODELAY is applicable to the socket and if so make the
> setsockopt failure be a fatal error in that case, but just a warning
> otherwise.

Since TCP_NODELAY is only applicable to TCP sockets, and the socket type 
for such sockets is SOCK_STREAM, we could ask

	int so_type;
	if (!getsockopt(fd, SOL_SOCKET, SO_TYPE,
			(char *)&so_type, sizeof(so_type)) &&
			so_type == SOCK_STREAM)

Hmm?

> I also include two convenience routines: rfbListenOnUnixSock(char *file) 
> and rfbAcceptUnixSock(int sock) so the user does not have to do these 
> activities manually.
> 
> But, what I have NOT done is to allow screen->listenSock be AF_UNIX
> (so the app still must manage the socket and call rfbNewClient() when
> a connection comes in.)  Doing this would involve more changes, and I
> believe also an ABI change to the screen structure; so I held off on
> thinking about how we might implement that or even if we wanted to.
> We can discuss that topic if anyone is interested.

What are the problems involved with calling rfbNewTCPOrUDPClient() on a 
unix socket?

For stdio communication, we'd need to split sock into two and identify 
where we read from, and where we write to the fd, right?

Ciao,
Dscho