Bug#645469: bind fails for AF_UNIX sockets with EINVAL
More importantly, there is the question you raised of whether this
should be done in userspace by libc instead. That would avoid
upstream having to wonder, "why should we care what happens when
someone using a BSD4.3-style bind() calls our BSD4.4-style kernel"?
So it's tempting.
Yes, I think this should be handled in glibc, and the sockaddr_un be
fixed to match what the kernel expects, the compat code would be there
to fix applications built against the bogus sockaddr_un type.
In fact, we already clip the passed size in our eglibc in
bind() and connect(), it might suffice in eglibc to
Index: glibc-ports/kfreebsd/sa_len.c
===================================================================
--- glibc-ports/kfreebsd/sa_len.c (revision 3738)
+++ glibc-ports/kfreebsd/sa_len.c (working copy)
@@ -37,7 +37,7 @@
case AF_IPX:
return sizeof (struct sockaddr_ipx);
case AF_LOCAL:
- return sizeof (struct sockaddr_un);
+ return sizeof (struct sockaddr_un) - 4;
}
return 0;
}
On the other hand we cannot change size of userland
sockaddr_un without ABI change. To do it correctly it would mean
to raise soname of eglibc and perform transition involving all packages.
I guess upstream would appreciate if we get rid of the length limit.
It sets the maximum path length for sockets to 104 chars, is that so?
I'm not entirely sure what you mean with that. If you mean making
sockaddr_un variable size, well that cannot be done, as it's expected
that sockaddr_storage can hold space for any sockaddr type.
May be the limit can be raised in upstream in kernel only,
to allow 108 instead of 104 only bytes.
The sockaddr_storage size is 128 bytes, the technical limit for sun_path
is therefore 126 bytes.
It would help in upstream kernel to the linux emulation layer.
Petr
Reply to: