2011/10/16 Petr Salinger <petr.salin...@seznam.cz>:
>> 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
Silent truncation sounds a bit dangerous. Could this introduce a
security problem? E.g. a malliciously placed socket which matches the
truncated path.
> 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.
Is that really so bad? I guess the impact is minimal. How many
libraries would make sockaddr_un part of their ABI?
> May be the limit can be raised in upstream in kernel only,
> to allow 108 instead of 104 only bytes.
Maybe. You mean something like this?
struct sockaddr_un
{
...
#ifdef _KERNEL
sun_path[108];
#else
sun_path[104];
#endif
}
It's ugly though. I wouldn't count on this being accepted, specially
not backported. If it doesn't serve us to support people running
upstream kernels, is there a point in pushing this change?
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
