Unix FD Passing

[Lennart Poettering]

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 
> fork()).

I actually didn't check for open() calls. And neither for fopen(). 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4