[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011/10/16 Petr Salinger <Petr.Salinger@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

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

Reply to: