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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to