[Xcb] [PATCH] Open the X11 socket with close-on-exec flag

[Rémi Denis-Courmont]

On Tue, 16 Feb 2010 12:29:50 +0100, Matthias Hopf <mhopf at suse.de> wrote:
> On Feb 15, 10 16:16:28 -0800, Barton C Massey wrote:
>> > It's a modularity issue. One component opened the X connection;
>> > another called fork(), usually promptly followed by exec(). Then the
>> > child has lost any record that it's sharing an FD with the parent,
>> > unless it goes probing the kernel's FD table.
>>
>> That's what I thought.
>>
>> IMHO this is an application problem, not specific or
>> interesting to XCB, and we shouldn't make it our problem.
>> Just saying.

A file descriptor is the sole problem of whatever allocated it. There is
simply no other *sane* responsibility rule in a thread-safe environment.
Yeah, library developer like to pretend that this is the "application
problem". Namely the application should have some kind of super mutex
whenever initializing the library.

This simply is not realistic. Imagine a call stack (reversed):
# Web browser
# Video plugin for the browser
# Phonon framework
# LibVLC
# LibVLC core
# PulseAudio output
# Xlib
# XCB
# Unix socket

Now how exactly do you tell the web browser to lock all accesses "fork"
when PulseAudio wants to get its cookie from the root window? You would
need to modify everything code path that can lead to a fork, or to XCB.
Instead of adding 4 lines (!) to XCB.

> If the child that is called is untrusted, the parent would have to make
> sure that no FDs are leaked. If the parent is multithreaded and using
> xcb, it should be clear to the parent that creating a new X connection
> could be racy in this aspect, and creating the X connection should only
> be done when all other threads are waiting on some mutex.

It's not a security issue. It's just about avoiding clogging up the system
and the X server with leaked connections (and allocated resources). It also
becomes a reliability problem if the parent crashes and the child remains
open - dangling X11 connection.

> IMHO this is not a security issue. It would be a nice-to-have security
> enhancement, but as this cannot be done architecture-agnostic, I don't
> think it is worth the hazzle.

This is not about security. This is about sound thread-safe API design.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis