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

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

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.

We do truncating already, only at 108, not at 104.
It could only match if the socket name will be really 104 bytes long.
The current situation with truncating is not worse than previous one.

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?

Affected might be all libraries which use sockaddr_un internally.
I just commited r3740 and r3739, at least one have to be active
with r3735 kernel.
I consider it cleanest way from current mess :-(


Reply to: