Util-Linux package development
 help / color / mirror / Atom feed
* Bad interaction between in.telnetd and login
@ 2016-01-14 23:29 Hua Zhong
  2016-01-15  0:19 ` Richard Weinberger
  0 siblings, 1 reply; 5+ messages in thread
From: Hua Zhong @ 2016-01-14 23:29 UTC (permalink / raw)
  To: richard, kzak, util-linux

[resend as pain text mode]

Hi,

While working on Fedora 18, we found that sometimes telnetd would
close connections unexpectedly:

Trying 172.24.17.14...
Connected to 172.24.17.14.
Escape character is '^]'.
Connection closed by foreign host.

in.telnetd runs login as its subprocess and communicates with it
through the pty master/slave descriptors. Initially reading the pty
master might return EIO, until the slave is ready. But if it gets EIO
after having read valid data, it breaks out.

What I find is that in.telnetd would sometimes get something like this
(25646 is login, and 25645 is telnetd) - getting EIO after reading
something:

25646 ioctl(0, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS,
{B9600 opost isig icanon echo ...}) = 0
25646 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B9600 opost isig icanon echo ...}) = 0
25646 close(0)                          = 0
25646 close(1)                          = 0
25646 close(2)                          = 0
25645 <... select resumed> )            = 1 (in [3])
25646 rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTART},  <unfinished ...>
25645 read(3,  <unfinished ...>
25646 <... rt_sigaction resumed> {SIG_IGN, [], 0}, 8) = 0
25645 <... read resumed> 0xf77a91c0, 8192) = -1 EIO (Input/output error)
25646 vhangup( <unfinished ...>
25645 select(4, [0 3], [], [0], NULL)   = 1 (in [3])
25645 read(3, "\3", 8192)               = 1
25645 select(1, [0], [0], [0], NULL)    = 1 (out [0])
25645 send(0, "\377", 1, MSG_OOB)       = 1
25645 select(1, [0], [0], [0], NULL)    = 1 (out [0])
25645 write(0, "\362", 1)               = 1
25645 select(4, [0 3], [], [0], NULL)   = 1 (in [3])
25645 read(3, 0xf77a91c0, 8192)         = -1 EIO (Input/output error)
<-- this is fatal

This used to work at least in fc14, but in fc18 it seems broken. It
happens intermittently.

The following thread caught my eye

https://lkml.org/lkml/2012/6/4/495

After removing the three close() functions before vhangup(), this
problem seems to go away. I suspect that this change caused bad
interaction between in.telnetd and login. The extra closes seem to
introduce EIO after something can be read from the pty master
descriptor. Now, you can argue that the bug should be in in.telnetd,
but I am not sure we want to break all the applications that depend on
the old login behavior.

I'd like to raise it to your attention and hear what you think the right fix is.

Hua Zhong

PS: Attached is the code snippet in login.c:

        tcgetattr(0, &tt);
        ttt = tt;
        ttt.c_cflag &= ~HUPCL;

        if ((fchown(0, 0, 0) || fchmod(0, cxt->tty_mode)) && errno != EROFS) {

                syslog(LOG_ERR, _("FATAL: %s: change permissions failed: %m"),
                                cxt->tty_path);
                sleepexit(EXIT_FAILURE);
        }

        /* Kill processes left on this tty */
        tcsetattr(0, TCSANOW, &ttt);

        /*
         * Let's close file decriptors before vhangup
         * https://lkml.org/lkml/2012/6/5/145
         */
        close(STDIN_FILENO);
        close(STDOUT_FILENO);
        close(STDERR_FILENO);

        signal(SIGHUP, SIG_IGN);        /* so vhangup() wont kill us */
        vhangup();
        signal(SIGHUP, SIG_DFL);

        /* open stdin,stdout,stderr to the tty */
        open_tty(cxt->tty_path);

        /* restore tty modes */
        tcsetattr(0, TCSAFLUSH, &tt);

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Bad interaction between in.telnetd and login
@ 2016-01-14 23:26 Hua Zhong
  2016-01-15 17:48 ` Karel Zak
  0 siblings, 1 reply; 5+ messages in thread
From: Hua Zhong @ 2016-01-14 23:26 UTC (permalink / raw)
  To: richard, kzak; +Cc: util-linux

[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

Hi,

While working on Fedora 18, we found that sometimes telnetd would close
connections unexpectedly:

Trying 172.24.17.14...
Connected to 172.24.17.14.
Escape character is '^]'.
Connection closed by foreign host.

in.telnetd runs login as its subprocess and communicates with it through
the pty master/slave descriptors. Initially reading the pty master might
return EIO, until the slave is ready. But if it gets EIO after having read
valid data, it breaks out.

What I find is that in.telnetd would sometimes get something like this
(25646 is login, and 25645 is telnetd) - getting EIO after reading
something:

25646 ioctl(0, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS,
{B9600 opost isig icanon echo ...}) = 0
25646 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B9600 opost isig icanon echo ...}) = 0
25646 close(0)                          = 0
25646 close(1)                          = 0
25646 close(2)                          = 0
25645 <... select resumed> )            = 1 (in [3])
25646 rt_sigaction(SIGHUP, {SIG_IGN, [HUP], SA_RESTART},  <unfinished ...>
25645 read(3,  <unfinished ...>
25646 <... rt_sigaction resumed> {SIG_IGN, [], 0}, 8) = 0
25645 <... read resumed> 0xf77a91c0, 8192) = -1 EIO (Input/output error)
25646 vhangup( <unfinished ...>
25645 select(4, [0 3], [], [0], NULL)   = 1 (in [3])
25645 read(3, "\3", 8192)               = 1
25645 select(1, [0], [0], [0], NULL)    = 1 (out [0])
25645 send(0, "\377", 1, MSG_OOB)       = 1
25645 select(1, [0], [0], [0], NULL)    = 1 (out [0])
25645 write(0, "\362", 1)               = 1
25645 select(4, [0 3], [], [0], NULL)   = 1 (in [3])
25645 read(3, 0xf77a91c0, 8192)         = -1 EIO (Input/output error) <--
this is fatal

This used to work at least in fc14, but in fc18 it seems broken. It happens
intermittently.

The following thread caught my eye

https://lkml.org/lkml/2012/6/4/495

After removing the three close() functions before vhangup(), this problem
seems to go away. I suspect that this change caused bad interaction between
in.telnetd and login. The extra closes seem to introduce EIO after
something can be read from the pty master descriptor. Now, you can argue
that the bug should be in in.telnetd, but I am not sure we want to break
all the applications that depend on the old login behavior.

I'd like to raise it to your attention and hear what you think the right
fix is.

Hua Zhong

PS: Attached is the code snippet in login.c:

        tcgetattr(0, &tt);
        ttt = tt;
        ttt.c_cflag &= ~HUPCL;

        if ((fchown(0, 0, 0) || fchmod(0, cxt->tty_mode)) && errno !=
EROFS) {

                syslog(LOG_ERR, _("FATAL: %s: change permissions failed:
%m"),
                                cxt->tty_path);
                sleepexit(EXIT_FAILURE);
        }

        /* Kill processes left on this tty */
        tcsetattr(0, TCSANOW, &ttt);

        /*
         * Let's close file decriptors before vhangup
         * https://lkml.org/lkml/2012/6/5/145
         */
        close(STDIN_FILENO);
        close(STDOUT_FILENO);
        close(STDERR_FILENO);

        signal(SIGHUP, SIG_IGN);        /* so vhangup() wont kill us */
        vhangup();
        signal(SIGHUP, SIG_DFL);

        /* open stdin,stdout,stderr to the tty */
        open_tty(cxt->tty_path);

        /* restore tty modes */
        tcsetattr(0, TCSAFLUSH, &tt);

[-- Attachment #2: Type: text/html, Size: 4632 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-15 17:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-14 23:29 Bad interaction between in.telnetd and login Hua Zhong
2016-01-15  0:19 ` Richard Weinberger
  -- strict thread matches above, loose matches on Subject: below --
2016-01-14 23:26 Hua Zhong
2016-01-15 17:48 ` Karel Zak
2016-01-15 17:57   ` Hua Zhong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox