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 toSilent 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 :-( Petr