GNOME Bugzilla – Bug 649480
Use MSG_CMSG_CLOEXEC in recvmsg in gio/gsocket.c
Last modified: 2011-05-05 18:31:09 UTC
The gsocket implementation should use the MSG_CMSG_CLOEXEC flag to recvmsg to receive the passed fds with the CLOEXEC flag already set when possible. This flag is useful for the same reasons as the O_CLOEXEC flag of open(2) See recvmsg(2).
Created attachment 187300 [details] [review] GSocket: Use MSG_CMSG_CLOEXEC This ensures received file descriptors don't leak to child processes.
Created attachment 187306 [details] [review] GSocket: Use MSG_CMSG_CLOEXEC Updates from IRC review by krh
For posterity: <walters> krh: bam, a patch <krh> walters: wowzers <walters> it's danw's ball probably <krh> woo, splinter! * krh reviews <krh> walters: well, basically, my comment is to just skip the fcntl loop if we have the CLOEXEC flag <walters> krh: hm though there is one detail here; we get complaints from people compiling against newer headers but running on old kernels this happens in autobuilder type scenarios we may need to check for EINVAL and if we have to handle that, we might as well do the fcntl <krh> walters: doesn't glibc handle that? <krh> fall back and emulate with fcntl internally <krh> walters: the other comments was, don't clear MSG_CMSG_CLOEXEC if the user set it in *flags <walters> from my glibc checkout as of sep 8 2010, nope oh true
Comment on attachment 187306 [details] [review] GSocket: Use MSG_CMSG_CLOEXEC >+#ifdef MSG_CMSG_CLOEXEC >+ if (result < 0 && get_socket_errno () == EINVAL) Arguably "&& !user_specified_cmsg_cloexec", but I guess we can just say that gio abstracts away the old kernel problem for the caller. >+ /* Filter out the Linux-only flag we added above; unless you don't need this part; recvmsg() overwrites msg.msg_flags
Created attachment 187308 [details] [review] GSocket: Use MSG_CMSG_CLOEXEC Updated for danw's comments
Attachment 187308 [details] pushed as 8932a1a - GSocket: Use MSG_CMSG_CLOEXEC