Dropbear channel request race condition?

Tim Broberg Tim.Broberg at servicenow.com
Thu Mar 20 06:37:20 WST 2014


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 log snippet below.)

If I don't send eof, it works fine.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dropbear_sudo.txt.gz
Type: application/x-gzip
Size: 3239 bytes
Desc: dropbear_sudo.txt.gz
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20140319/410af4bb/attachment.bin 


More information about the Dropbear mailing list