bug#23068: 25.1.50; unix socket address in abstract namespace

bug#23068: 25.1.50; unix socket address in abstract namespace

[Mark Oteiza]

For the wishlist: teach emacs how to handle unix domain sockets with
an abstract address.  For instance, connecting to an abstract address
might look like:

  (make-network-process
   :name "dog" :buffer " *woof*"
   :service "\0sock" :family 'local)

the salient part being that the first element of the address is a null
byte. unix(7) has details.

In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2016-03-19 built on duoteque
Repository revision: 326fff41fa9f674d80be00b5c97c44f8043bbace
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --without-gconf --with-modules
 --with-x-toolkit=lucid 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong --param=ssp-buffer-size=4 -g
 -fvar-tracking-assignments -g -fvar-tracking-assignments'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 MODULES

bug#23068: 25.1.50; unix socket address in abstract namespace

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 19 Mar 2016 23:18:35 -0400
> 
> For the wishlist: teach emacs how to handle unix domain sockets with
> an abstract address.  For instance, connecting to an abstract address
> might look like:
> 
>   (make-network-process
>    :name "dog" :buffer " *woof*"
>    :service "\0sock" :family 'local)
> 
> the salient part being that the first element of the address is a null
> byte. unix(7) has details.

Which parts of this don't already work?

bug#23068: 25.1.50; unix socket address in abstract namespace

[Mark Oteiza]

On 20/03/16 at 06:32pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Sat, 19 Mar 2016 23:18:35 -0400
> > 
> > For the wishlist: teach emacs how to handle unix domain sockets with
> > an abstract address.  For instance, connecting to an abstract address
> > might look like:
> > 
> >   (make-network-process
> >    :name "dog" :buffer " *woof*"
> >    :service "\0sock" :family 'local)
> > 
> > the salient part being that the first element of the address is a null
> > byte. unix(7) has details.
> 
> Which parts of this don't already work?

For testing purposes, the socket is bound with

  socat -vd abstract-listen:sock,fork TCP:host:port

and I'm able to connect to it otherwise. The above elisp does:

  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
  connect(8, {sa_family=AF_LOCAL, sun_path=@""}, 110) = -1 ECONNREFUSED (Connection refused)
  close(8) 

bug#23068: 25.1.50; unix socket address in abstract namespace

[Lars Magne Ingebrigtsen]

Mark Oteiza <mvoteiza@udel.edu> writes:

> and I'm able to connect to it otherwise. The above elisp does:
>
>   socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
>   connect(8, {sa_family=AF_LOCAL, sun_path=@""}, 110) = -1
> ECONNREFUSED (Connection refused)
>   close(8) 

Yeah, this code in conv_lisp_to_sockaddr doesn't look very correct:

  else if (STRINGP (address))
    {
#ifdef HAVE_LOCAL_SOCKETS
      if (family == AF_LOCAL)
	{
	  struct sockaddr_un *sockun = (struct sockaddr_un *) sa;
	  cp = SDATA (address);
	  for (i = 0; i < sizeof (sockun->sun_path) && *cp; i++)
	    sockun->sun_path[i] = *cp++;
	  sa->sa_family = family;
	}
#endif
      return;
    }


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23068: 25.1.50; unix socket address in abstract namespace

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23068@debbugs.gnu.org
> Date: Sun, 20 Mar 2016 18:11:09 +0100
> 
> Mark Oteiza <mvoteiza@udel.edu> writes:
> 
> > and I'm able to connect to it otherwise. The above elisp does:
> >
> >   socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
> >   connect(8, {sa_family=AF_LOCAL, sun_path=@""}, 110) = -1
> > ECONNREFUSED (Connection refused)
> >   close(8) 
> 
> Yeah, this code in conv_lisp_to_sockaddr doesn't look very correct:
> 
>   else if (STRINGP (address))
>     {
> #ifdef HAVE_LOCAL_SOCKETS
>       if (family == AF_LOCAL)
> 	{
> 	  struct sockaddr_un *sockun = (struct sockaddr_un *) sa;
> 	  cp = SDATA (address);
> 	  for (i = 0; i < sizeof (sockun->sun_path) && *cp; i++)
> 	    sockun->sun_path[i] = *cp++;
> 	  sa->sa_family = family;
> 	}
> #endif
>       return;
>     }

That should be trivial to fix.  Elsewhere, we specifically attempt to
support this feature:

  #ifdef HAVE_LOCAL_SOCKETS
      case AF_LOCAL:
	{
	  struct sockaddr_un *sockun = (struct sockaddr_un *) sa;
	  ptrdiff_t name_length = len - offsetof (struct sockaddr_un, sun_path);
	  /* If the first byte is NUL, the name is a Linux abstract
	     socket name, and the name can contain embedded NULs.  If
	     it's not, we have a NUL-terminated string.  Be careful not
	     to walk past the end of the object looking for the name
	     terminator, however.  */
	  if (name_length > 0 && sockun->sun_path[0] != '\0')
	    {
	      const char *terminator
		= memchr (sockun->sun_path, '\0', name_length);

	      if (terminator)
		name_length = terminator - (const char *) sockun->sun_path;
	    }

	  return make_unibyte_string (sockun->sun_path, name_length);
	}

IOW, this is not a wishlist feature request, but a routine bug report ;-)

bug#23068: 25.1.50; unix socket address in abstract namespace

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Mark Oteiza <mvoteiza@udel.edu> writes:
>
>> and I'm able to connect to it otherwise. The above elisp does:
>>
>>   socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
>>   connect(8, {sa_family=AF_LOCAL, sun_path=@""}, 110) = -1
>> ECONNREFUSED (Connection refused)
>>   close(8) 
>
> Yeah, this code in conv_lisp_to_sockaddr doesn't look very correct:
>
>   else if (STRINGP (address))
>     {
> #ifdef HAVE_LOCAL_SOCKETS
>       if (family == AF_LOCAL)
> 	{
> 	  struct sockaddr_un *sockun = (struct sockaddr_un *) sa;
> 	  cp = SDATA (address);
> 	  for (i = 0; i < sizeof (sockun->sun_path) && *cp; i++)
> 	    sockun->sun_path[i] = *cp++;

This also needs to encode the string in one way.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23068: 25.1.50; unix socket address in abstract namespace

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sun, 20 Mar 2016 18:39:02 +0100
> Cc: Mark Oteiza <mvoteiza@udel.edu>, 23068@debbugs.gnu.org
> 
> This also needs to encode the string in one way.

The network-related functions in process.c generally don't bother
encoding the strings at all.

bug#23068: 25.1.50; unix socket address in abstract namespace

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Sun, 20 Mar 2016 18:39:02 +0100
>> Cc: Mark Oteiza <mvoteiza@udel.edu>, 23068@debbugs.gnu.org
>> 
>> This also needs to encode the string in one way.
>
> The network-related functions in process.c generally don't bother
> encoding the strings at all.

That doesn't mean it is correct.  A file name needs to be encoded.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#23068: 25.1.50; unix socket address in abstract namespace

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mvoteiza@udel.edu,  larsi@gnus.org,  23068@debbugs.gnu.org
> Date: Sun, 20 Mar 2016 20:49:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Date: Sun, 20 Mar 2016 18:39:02 +0100
> >> Cc: Mark Oteiza <mvoteiza@udel.edu>, 23068@debbugs.gnu.org
> >> 
> >> This also needs to encode the string in one way.
> >
> > The network-related functions in process.c generally don't bother
> > encoding the strings at all.
> 
> That doesn't mean it is correct.

No, of course not.  What it means is that many more places need to be
fixed in this regard.