[PATCH 2/2] Xinit: close stdin to avoid leak of file descriptior to the Xorg session.

[Jeremy Huddleston]

On Jul 26, 2011, at 1:34 PM, Ray Strode wrote:

> Hi,
> 
> On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston <jeremyhu at apple.com> wrote:
>> IMO, there is a point to closing stdin aside from the setsid(2).
> My point is, it only solves the problem part way.

Well, the problem you are reporting is 2 parted, hence you should have 2 commits.  The stdin closing is an issue in its own right and should be a separate patch.

You're also assuming that startx(1) is started from a tty.  That's not always the case.  On darwin, it's usually not started from a tty, and I don't think that I want to do a setsid(2) in that case.  Perhaps you should check isatty(2) before doing a setsid(2).  I'd be fine with that since it'd be a nop on darwin.  stdin is already closed on darwin, so the whole changeset is a nop for us, but I'm more concerned about how this might effect others.  The stdin issue is much more obvious, and the setsid(2) issue I feel is a bit more debatable.  That's why I suggest you get in the other patch now and we can just focus our discussion on setsid(2).

> As an example, say a program wants to ask the user for a password.
> The program supports asking the user at the console if run from a tty,
> and supports asking the user from an X dialog otherwise.  The way that
> program would ask the user for a password at the console is by opening
> /dev/tty (since password programs don't read input from stdin).  That
> program could first try to open /dev/tty, and if it fails assume an X
> fall back.  If you haven't insulated the client from the tty startx
> was run on, then this program may end up trying to ask for a password
> on some switched away VT! and would probably get suspended instantly
> with SIGTTIN.  You could argue the client should try X first and fall
> back to console.  Or you could argue the client should do isatty() on
> stdin before trying to open /dev/tty.  But both are debatable and this
> is just one example, anyway.
> 
> The example serves to show that redirecting STDIN to /dev/null
> partially solves the same problem setsid partially solves.That problem
> is "detaching X clients from the tty startx was run on".
> 
> Or is there another problem being solved, that you have in mind?
> 
> --Ray
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>