Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-17 Thread Petr Salinger
Btw, could we restrict this kludge to platforms that need it? See attached patch. I like the idea, slightly different patch is in. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-17 Thread Robert Millan
2011/10/17 Robert Millan : > 2011/10/17 Petr Salinger : >> I just commited r3740 and r3739, at least one have to be active >> with r3735 kernel. Btw, could we restrict this kludge to platforms that need it? See attached patch. -- Robert Millan Index: sys/un.h ===

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-17 Thread Robert Millan
2011/10/17 Petr Salinger : > I just commited r3740 and r3739, at least one have to be active > with r3735 kernel. > I consider it cleanest way from current mess :-( Yeah, I guess when the problem is so ugly the solution must be ugly too :-( Have you tested r3740? Btw, you forgot kfreebsd-{9,10}

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-17 Thread Petr Salinger
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 suffi

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-17 Thread Robert Millan
2011/10/16 Petr Salinger : >> 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

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Petr Salinger
More importantly, there is the question you raised of whether this should be done in userspace by libc instead.  That would avoid upstream having to wonder, "why should we care what happens when someone using a BSD4.3-style bind() calls our BSD4.4-style kernel"? So it's tempting. Yes, I think th

Bug#645469: bind fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Petr Salinger
More importantly, there is the question you raised of whether this should be done in userspace by libc instead. That would avoid upstream having to wonder, "why should we care what happens when someone using a BSD4.3-style bind() calls our BSD4.4-style kernel"? So it's tempting. For now I prop

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Guillem Jover
On Sun, 2011-10-16 at 13:44:29 +0200, Robert Millan wrote: > 2011/10/16 Jonathan Nieder : > > More importantly, there is the question you raised of whether this > > should be done in userspace by libc instead.  That would avoid > > upstream having to wonder, "why should we care what happens when >

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Robert Millan
2011/10/16 Jonathan Nieder : > More importantly, there is the question you raised of whether this > should be done in userspace by libc instead.  That would avoid > upstream having to wonder, "why should we care what happens when > someone using a BSD4.3-style bind() calls our BSD4.4-style kernel"?

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Jonathan Nieder
Jonathan Nieder wrote: > --- i/sys/kern/uipc_syscalls.c > +++ w/sys/kern/uipc_syscalls.c > @@ -1703,11 +1703,18 @@ getsockaddr(namp, uaddr, len) [...] > sa->sa_len = len; > + datalen = len - offsetof(struct sockaddr, sa_data[0]); > + p = memchr(sa->sa_data, '\

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Jonathan Nieder
Robert Millan wrote: > 2011/10/16 Jonathan Nieder : >>        unsigned char sun_len; >>        unsigned char sun_family; >>        char sun_path[108];     /* Path name. */ > > Is this 108 the actual length? ISTR it was just a placeholder. It's the actual size of the sun_path field of struct sock

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Robert Millan
2011/10/16 Jonathan Nieder : > Here's "struct sockaddr_un" in eglibc (socket/sys/un.h, after a little > typedef-chasing): > >        unsigned char sun_len; >        unsigned char sun_family; >        char sun_path[108];     /* Path name. */ Is this 108 the actual length? ISTR it was just a placeh

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Jonathan Nieder
Robert Millan wrote: > http://security.freebsd.org/patches/SA-11:05/unix.patch Thanks for the pointer. Here's "struct sockaddr_un" in eglibc (socket/sys/un.h, after a little typedef-chasing): unsigned char sun_len; unsigned char sun_family; char sun_path[108]; /* Pat

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-16 Thread Robert Millan
2011/10/16 Jonathan Nieder : >        E: unable to bind server socket to file '/tmp/cuptyL8GPC': Invalid > argument >        E: error performing command 'update' > > By contrast, kfreebsd-image-8.2-1-amd64 8.2-8+gcc45 works fine. > > Trying to track this down, I tried the example from the bind(2)

Bug#645469: bind() fails for AF_UNIX sockets with EINVAL

2011-10-15 Thread Jonathan Nieder
Package: kfreebsd-9 Version: 9.0~svn225873 Severity: important Hi, Typical kfreebsd-amd64 experimental system. When I try to use "cupt update" after booting with kfreebsd 9, it always fails: E: unable to bind server socket to file '/tmp/cuptyL8GPC': Invalid argument E: error pe