Unix FD Passing
mzqohf at 0pointer.de
Fri Apr 24 19:01:49 PDT 2009
On Sat, 25.04.09 01:13, Thiago Macieira (thiago at kde.org) wrote:
> > There are some other changes in the repo too: a few commits regarding
> > FD_CLOEXEC: newer linux kernels have support for SOCK_CLOEXEC which
> > allows sockets to be created with O_CLOEXEC set right-away. This
> > closes a race condition where some other thread might fork/exec while
> > dbus allocated an fd and hasn't yet set FD_CLOEXEC. Given how
> > fundamental D-Bus is it is certainly good idea to fix this race.
> Thanks, I was going to do that myself (I'm doing the same for Qt and I sent a
> patch to glib), but you beat me to the punch here.
> On that:
> db2a3283 and 96a70e0a
> - older kernels will return EINVAL for the "| SOCK_CLOEXEC" case
> you need to try again without
> 808ceff7 and df664ffe
> - same thing: you may be on a glibc that has pipe2/accept4, but the kernel
> doesn't, so the call will return ENOSYS and you should try again
Hmpf. Ignorant me assumed that GLIBC would emulate this for
me. Bah. Sometimes glibc really could be friendlier to use.
> I didn't find any dup or dup2 calls that needed fixing (all dup2 are after
I actually didn't check for open() calls. And neither for fopen().
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus