Abstract namespace connections (Connection refused)

[@4u]

Thanks for your quick reply :)

What does the D-BUS do? Does it append NUL bytes?

If a C programmer finds this line:

memcpy(unix_addr->sun_path, xparam->inputs.name, xparam->inputs.namelen);

Does it mean that NUL bytes are their or not?

Context:

#ifdef AF_UNIX
static inline int parse_unix_address(php_stream_xport_param *xparam,
struct sockaddr_un *unix_addr TSRMLS_DC)
{
	memset(unix_addr, 0, sizeof(*unix_addr));
	unix_addr->sun_family = AF_UNIX;

	/* we need to be binary safe on systems that support an abstract
	 * namespace */
	if (xparam->inputs.namelen >= sizeof(unix_addr->sun_path)) {
		/* On linux, when the path begins with a NUL byte we are
		 * referring to an abstract namespace.  In theory we should
		 * allow an extra byte below, since we don't need the NULL.
		 * BUT, to get into this branch of code, the name is too long,
		 * so we don't care. */
		xparam->inputs.namelen = sizeof(unix_addr->sun_path) - 1;
	}

	memcpy(unix_addr->sun_path, xparam->inputs.name, xparam->inputs.namelen);

	return 1;
}
#endif

Havoc Pennington schrieb:
> Hi,
> 
> On Thu, Feb 14, 2008 at 4:33 PM, @4u <fd4u at vplace.de> wrote:
>>  I thought it's enough to connect to a real or abstract socket via its
>>  path. If I try to connect to an FAM socket in the abstract namespace, it
>>  works. Unfortunately I get "Connection refused" if I try to open a user
>>  session in /tmp/. What's special with the user session sockets? The
>>  process trying to connect has the same uid and pid as the owner of the
>>  socket - so this can't be the reason, right?
> 
> There aren't any permissions (plus in the abstract namespace, the use
> of /tmp in the name is just misleading; it doesn't matter whether the
> name looks like a filesystem path, it's just a string).
> 
> Most likely you are passing the wrong length to the socket functions.
> The abstract name is allowed to have nul bytes in it. So if you say
> the length is 255, 255 bytes are used, even if you have a nul after
> /tmp/whatever.
> 
> Havoc