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

[Matthias Hopf]

On Feb 16, 10 13:06:23 +0100, Rémi Denis-Courmont wrote:
> On Tue, 16 Feb 2010 12:29:50 +0100, Matthias Hopf <mhopf at suse.de> wrote:
> >> 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.

Hm. I understand your reasoning, but if you're running untrusted
components, you're always on your own. I would never count system
libraries to untrusted components.

Principally, I would love to have your patch applied, but as long as
this is Linux-only I see little advantage in it.

> > 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

Sorry, but the main reason I (personally) would find these system
dependent fixes acceptable are security issues. It even *could* be
argued that we're talking about a security issue.

However, I don't have a strong opinion against it. If it's consensus
that this is something great, I'm good with it.

> becomes a reliability problem if the parent crashes and the child remains
> open - dangling X11 connection.

I'm having a hard time imagining a situation where a X11-aware process
forks and execs a not-X11-aware where the child would live over the
parents death. I'm not saying there is none, I just don't know any.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de