[Spice-devel] [PATCH spice-server v2] RFC: Support abstract Unix sockets

[Frediano Ziglio]

> 
> On Wed, Nov 22, 2017 at 12:11:33PM +0000, Frediano Ziglio wrote:
> > Allows to specify abstract Unix sockets addresses.
> > These Unix sockets are supported on Linux and allows to not
> > have file system names.
> 
> What would be the use-case? Just cleaner not to have a dummy path in the
> FS? Or does it bring more? I'd say why not, though a spice-gtk patch
> will be needed too.
> 

They have pro and cons. As said they don't have a FS name so for instance
programs running on some chroot can access the sockets too. For instance
recent Xorg bind to @/tmp/.X11-unix/X<num> also.
Also you don't need to unlink the FS entry at the end. This could avoid
to do the cleanup from libvirt.
On the cons not having a FS prevent easily to change permissions on the
socket.

> 
> > 
> > Signed-off-by: Frediano Ziglio <fziglio at redhat.com>
> > ---
> >  server/reds.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > Changes since v1:
> > - do not unlink no file socket.
> > 
> > diff --git a/server/reds.c b/server/reds.c
> > index ebcbe496..ca0bb75a 100644
> > --- a/server/reds.c
> > +++ b/server/reds.c
> > @@ -2585,8 +2585,12 @@ static int reds_init_socket(const char *addr, int
> > portnr, int family)
> >  
> >          local.sun_family = AF_UNIX;
> >          g_strlcpy(local.sun_path, addr, sizeof(local.sun_path));
> > -        unlink(local.sun_path);
> >          len = SUN_LEN(&local);
> > +        if (local.sun_path[0] == '@') {
> > +            local.sun_path[0] = 0;
> > +        } else {
> > +            unlink(local.sun_path);
> > +        }
> >          if (bind(slisten, (struct sockaddr *)&local, len) == -1) {
> >              perror("bind");
> >              return -1;