GNU bug report logs - #23068
25.1.50; unix socket address in abstract namespace

Previous Next

To reply to this bug, email your comments to 23068 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; unix socket address in abstract namespace
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.

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

Message #8 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 18:32:17 +0200

> From: Mark Oteiza <mvoteiza <at> 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?

Message #11 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Mark Oteiza <mvoteiza <at> udel.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 13:02:12 -0400

On 20/03/16 at 06:32pm, Eli Zaretskii wrote:
> > From: Mark Oteiza <mvoteiza <at> 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) 

Message #14 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Mark Oteiza <mvoteiza <at> udel.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 18:11:09 +0100

Mark Oteiza <mvoteiza <at> 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

Message #17 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: mvoteiza <at> udel.edu, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 19:25:13 +0200

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  23068 <at> debbugs.gnu.org
> Date: Sun, 20 Mar 2016 18:11:09 +0100
> 
> Mark Oteiza <mvoteiza <at> 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 ;-)

Message #20 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Mark Oteiza <mvoteiza <at> udel.edu>, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 18:39:02 +0100

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

> Mark Oteiza <mvoteiza <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #23 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: mvoteiza <at> udel.edu, larsi <at> gnus.org, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 20:02:16 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Date: Sun, 20 Mar 2016 18:39:02 +0100
> Cc: Mark Oteiza <mvoteiza <at> udel.edu>, 23068 <at> 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.

Message #26 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mvoteiza <at> udel.edu, larsi <at> gnus.org, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 20:49:31 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Date: Sun, 20 Mar 2016 18:39:02 +0100
>> Cc: Mark Oteiza <mvoteiza <at> udel.edu>, 23068 <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #29 received at 23068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: mvoteiza <at> udel.edu, larsi <at> gnus.org, 23068 <at> debbugs.gnu.org
Subject: Re: bug#23068: 25.1.50; unix socket address in abstract namespace
Date: Sun, 20 Mar 2016 21:51:52 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: mvoteiza <at> udel.edu,  larsi <at> gnus.org,  23068 <at> debbugs.gnu.org
> Date: Sun, 20 Mar 2016 20:49:31 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab <at> linux-m68k.org>
> >> Date: Sun, 20 Mar 2016 18:39:02 +0100
> >> Cc: Mark Oteiza <mvoteiza <at> udel.edu>, 23068 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.