Dropbear channel request race condition?

[Matt Johnston]

Hi,

I'm not sure whether it's possible to use EOF like that for a
session with a PTY terminal. 

For a PTY session it will have a single file descriptor
(returned from openpty() or similar) for both stdin and
stdout. Dropbear's behaviour on receiving a EOF is to close
the stdin for the process (assuming no write data is
pending), then let the process deal with it. For the PTY
case closing that file descriptor will also close stdout.

For TCP channels Dropbear uses shutdown() to close each
direction independently, but I don't think that will work
with a PTY - anyone know?

Have you come across any programs that aren't flushing
buffers? Does running without a terminal work OK with your
EOF-sending program?  I tried to make a quick change to send
a eof straight away but can't replicate it.

(As a side-note I hit the same hassle with sudo needing a
terminal this week - annoying!)

Cheers,
Matt


On Thu, Mar 20, 2014 at 05:48:51PM +0000, Tim Broberg wrote:
> For reasons which may, or may not be, pathological, I'm working on
> developing
> an SSH client. I'm running into problems executing commands in a terminal
> on
> dropbear.
> 
> I'm sending an exec request to a session with a terminal (so I can run
> sudo commands).
> 
> I send the channel request, then send eof expecting to get data, exit
> status, and eof back.
> 
> Instead, dropbear server sends eof right away, then the running command
> fails because his terminal has been shut down. (See the last 3 lines of
> the server log snippet below.)
> 
> If I don't send eof, it works fine, but then I worry about other processes
> /
> Servers not flushing buffers out until they see eof.
> 
> I would expect dropbear to wait for the outstanding channel request to run
> to completion before sending eof.
> 
> Am I making sense, or is there some problem with my use case of requesting
> exec from a terminal session? If this is considered an invalid use case,
> what would you suggest as an appropriate usage / workaround?
> 
> The full log is attached, and an excerpt from receipt of eof to the
> failure of the command due to terminal non-existence is below.
> 
> Thanks for any help you're able to provide,
>     - Tim.
> 
> TRACE (2354): enter recv_msg_channel_eof
> TRACE (2354): check_close: writefd 6, readfd 6, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd 6
> TRACE (2354): enter send_msg_channel_eof
> TRACE (2354): enter encrypt_packet()
> TRACE (2354): encrypt_packet type is 96
> TRACE (2354): enter writemac
> TRACE (2354): leave writemac
> TRACE (2354): enter enqueue
> TRACE (2354): leave enqueue
> TRACE (2354): leave encrypt_packet()
> TRACE (2354): leave send_msg_channel_eof
> TRACE (2354): leave recv_msg_channel_eof
> TRACE (2354): leave process_packet
> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd -1
> TRACE (2354): enter write_packet
> TRACE (2354): empty queue dequeing
> TRACE (2354): leave write_packet
> TRACE (2354): check_close: writefd -1, readfd -1, errfd -1, sent_close 0,
> recv_close 0
> TRACE (2354): writebuf size 0 extrabuf size 0
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): sesscheckclose, pid is -1
> TRACE (2354): CLOSE some fd -1
> TRACE (2356): back to normal sigchld
> [2356] Mar 19 14:13:12 ioctl(TIOCSCTTY): Input/output error
> [2356] Mar 19 14:13:12 /dev/pts/1: No such file or directory
> [2356] Mar 19 14:13:12 open /dev/tty failed - could not set controlling
> tty: No such device or address
> 
> 
>