Unix FD Passing
thiago at kde.org
Fri Apr 24 16:13:58 PDT 2009
Em Sexta-feira 24 Abril 2009, às 18:55:16, Lennart Poettering escreveu:
> This also includes simple negotiation for unix fd passing: the auth
> protocol is extended a bit. Two new commands have been introduced. If
> a clients can do and wants to do fd passing it will send
> NEGOTIATE-UNIX-FD after the authentication was sucessful, before
> sending BEGIN. The server then responds with ERROR if it cannot or
> doesn't want to do fd passing. Otherwise it will respond with
> AGREE-UNIX-FD and both sides enable their fd passing code.
Brilliant solution! Why didn't we think of that before?
> 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.
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
I didn't find any dup or dup2 calls that needed fixing (all dup2 are after
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Software
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090425/8edda234/attachment.pgp
More information about the dbus