+++ This bug was initially created as a clone of Bug #139597 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
When xterm starts the shell there are four open instances of the tty,
there should only be three. This means the leaked fd may be inherited
by any descendant from the xterm.

Version-Release number of selected component (if applicable):
xterm-179-6.EL

How reproducible:
Always

Steps to Reproduce:
1. Start an xterm
2. Type: ls -l /prof/self/fd


Actual Results:  
[kasperd@marvin kasperd]$ ls -l /proc/self/fd
total 5
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 0 -> /dev/pts/3
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 1 -> /dev/pts/3
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 2 -> /dev/pts/3
lr-x------  1 kasperd kasperd 64 Nov 16 22:20 3 -> /proc/3812/fd
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 9 -> /dev/pts/3
[kasperd@marvin kasperd]$ 


Expected Results:  
[kasperd@marvin kasperd]$ ls -l /proc/self/fd
total 5
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 0 -> /dev/pts/3
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 1 -> /dev/pts/3
lrwx------  1 kasperd kasperd 64 Nov 16 22:20 2 -> /dev/pts/3
lr-x------  1 kasperd kasperd 64 Nov 16 22:20 3 -> /proc/3812/fd
[kasperd@marvin kasperd]$ 


Additional info:

Some shells may close leaked filedescriptors hiding the symptoms of
the xterm bug. However the symptoms are visible as long as bash is
being used as shell.

-- Additional comment from dickey on 2004-11-29 19:31 EST --
Perhaps it depends on the kernel/pty implementation.  On
Debian/testing with 2.4.27, I see this:

~ (1) ls -l /proc//self/fd
total 4
lrwx------  1 tom tom 64 Nov 29 19:33 0 -> /dev/pts/4
lrwx------  1 tom tom 64 Nov 29 19:33 1 -> /dev/pts/4
lrwx------  1 tom tom 64 Nov 29 19:33 2 -> /dev/pts/4
lr-x------  1 tom tom 64 Nov 29 19:33 3 -> /proc/8226/fd
~ (2) 


-- Additional comment from dickey on 2004-11-29 19:32 EST --
Sorry - that was tcsh.  With bash I see this (will check more).

tom@crayon:/usr/build/xterm/xterm-196j$ ls -l /proc/self/fd
total 5
lrwx------  1 tom tom 64 Nov 29 19:35 0 -> /dev/pts/5
lrwx------  1 tom tom 64 Nov 29 19:35 1 -> /dev/pts/5
lrwx------  1 tom tom 64 Nov 29 19:35 2 -> /dev/pts/5
lr-x------  1 tom tom 64 Nov 29 19:35 3 -> /proc/8235/fd
lrwx------  1 tom tom 64 Nov 29 19:35 9 -> /dev/pts/5
tom@crayon:/usr/build/xterm/xterm-196j$ 




-- Additional comment from dickey on 2004-11-29 20:25 EST --
File-descriptor 9 appears to be the one opened in main.c by
this chunk:
                if ((pty_name = ptsname(screen->respond)) == 0) {
                    SysError(ERROR_PTSNAME);
                }
                if ((ptyfd = open(pty_name, O_RDWR)) < 0) {
                    SysError(ERROR_OPPTSNAME);
                }
and ptyfd is used for a while before copying it to the tty variable.
That is next updated by opening /dev/tty in a thicket of ifdef's.
So it's simple to see, hard to fix (will study this and try to not
break it ;-).

-- Additional comment from mharris on 2004-12-22 08:47 EST --
Does this occur in FC3 and/or other OS releases as well?


-- Additional comment from mharris on 2004-12-22 08:49 EST --
CC'ing RH Security team as there may be possible security implications
to leaking FDs.  Any comments appreciated.

-- Additional comment from dickey on 2004-12-22 08:53 EST --
Probably (I verified this on Debian/testing).
The related code hasn't changed for a while.

-- Additional comment from alan on 2004-12-22 09:13 EST --
Don't see any immediately - the user owns the pty and tty sides of
their connection so they could just open the file again anyway. You
can probably do annoying things with it - but only to yourself


-- Additional comment from dickey on 2005-01-16 10:02 EST --
fixed:
http://invisible-island.net/xterm/xterm.log.html#xterm_198

-- Additional comment from mharris on 2005-02-01 05:34 EST --
Targetting for FC4 for review.  We probably will update to this
new xterm version for FC4, but we should also try to isolate
the patch that fixes this for consideration for FC3 and FC2 also.


-- Additional comment from mharris on 2005-02-01 05:37 EST --
Thomas:  You wouldn't happen to have a patch, or CVS diff of
just the fix for this would you?  If so, I can apply the fix
alone for FC2 and FC3 and update them for those releases
possibly.

We'll put the new xterm into FC4 development soon too.

Thanks.


Setting to "NEEDINFO", to find out if there's a minimal patch
available.

-- Additional comment from dickey on 2005-02-01 06:10 EST --
yes - I made a note to do this when I get home this afternoon

-- Additional comment from mharris on 2005-02-01 06:15 EST --
Thanks Thomas!

-- Additional comment from dickey on 2005-02-01 20:19 EST --
Created an attachment (id=110537)
fix for file-descriptor leak.

hmm - longer than I'd like, but that's because I changed a variable
name (too many "tty" substrings to read).

-- Additional comment from mharris on 2005-02-07 20:43 EST --
Thanks for the patch Thomas, we'll review it for the next xterm
update for FC.


-- Additional comment from mharris on 2005-02-07 20:47 EST --
Status:

For FC4:
xterm needs to be updated to latest version.  Once that's done,
we can remove the FC4 tracker bugs, and leave the issue open for
other releases.

For FC2/FC3/RHEL3/RHEL4:
The patch in comment #13 needs to be reviewed by someone to determine
if it is worthy of updating xterm for.  We'll probably want to
simplify the patch if we include it.



-- Additional comment from sandmann on 2005-03-22 11:03 EST --
For FC4, xterm is already updated to the latest version. 

For FC3/FC2/RHEL, I don't think it's worth it unless there are security
implications. So this bug can be closed NEXTRELEASE imo.


-- Additional comment from mharris on 2005-04-10 22:14 EST --
Changing bug target to FC3Updates, as we've got the newest xterm with these
fixes in FC4 already.  Removing from FC4Target.


-- Additional comment from mharris on 2005-04-15 09:30 EST --
FC2 is end-of-life now, but when we fix this one:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148921

... we'll pull in the fix for this and a bunch of others for free.

-- Additional comment from wtogami on 2005-05-22 23:29 EST --
Do you actually intend on issuing an FC3 update?  If not then set WONTFIX or
something.

-- Additional comment from mitr on 2006-03-05 06:52 EST --
xterm-209-2 in rawhide contains the upstream fix.

Does this still need to be open, considering FC3 has reached its EOL?

-- Additional comment from bugzilla.net on 2006-03-05 11:13 EST --
I couldn't reproduce the problem with xterm-208-2.FC4

-- Additional comment from jvdias on 2006-03-15 19:14 EST --
This is bug is fixed in all current versions of Fedora; it does not appear to
affect RHEL-3, but does affect RHEL-4. Closing this bug, and cloning as a RHEL-4
bug.