Is this a bug? 2: the return
Philippe Brand
philippe.brand at safe-protect.com
Thu Dec 6 01:18:31 WST 2007
Rob Landley wrote:
>
> It's not a question of "fork", it's a question of the parent process exiting.
> When the program you run via ssh exits, ssh should exit. It doesn't matter
> what background processes it left running.
>
> Does your program do what you want if you use "telnet" instead of ssh?
>
>
I completly agree, fork() has nothing to do there, as my latest attemps
shows it. My main concerns is that parent process does *not* exit. debug
traces on remote system continues to shows up after ssh session is
killed on calling system.
Some additional notes:
In fact everything works fine if dbclient command is run interactively
from shell (>=0.48.1). Problem only occurs when command is run from cgi
(for dropbear versions >=0.49, as 0.48.1 works fine called from cgi).
I recompiled dbclient 0.50 using DEBUG_TRACE and -v
Interactive trace / Cgi trace
(beginning of trace stricly identical for both methods)
....
enter cli_sessionloop
enter read_packet
enter decrypt_packet
leave decrypt_packet
leave read_packet
enter process_packet
process_packet: packet type = 91
enter recv_msg_channel_open_confirmation
new chan remote 0 local 0
setnonblocking: 1
leave setnonblocking
setnonblocking: 0
leave setnonblocking
setnonblocking: 2
leave setnonblocking
enter send_chansess_shell_req
enter encrypt_packet()
encrypt_packet type is 98
enter buf_compress
leave buf_compress
enter writemac
leave writemac
enter enqueue
leave enqueue
leave encrypt_packet()
leave send_chansess_shell_req
leave recv_msg_channel_open_confirmation
leave process_packet
check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0
writebuf size 0 extrabuf size 0
enter cli_sessionloop
enter write_packet
empty queue dequeing
leave write_packet
Here comes differences:
check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0
send normal readfd
writebuf size 0 extrabuf size 0
enter send_msg_channel_data
enter cli_sessionloop
enter send_msg_channel_data isextended
0 fd 0
enter read_packet
maxlen 16375
enter decrypt_packet
CLOSE some fd 0
leave decrypt_packet
leave send_msg_channel_data: len 0
read err 17 or EOF for fd 0
leave read_packet
check_close: writefd 1, readfd -1,
errfd 2, sent_close 0, recv_close 0
enter process_packet
writebuf size 0 extrabuf size 0
process_packet: packet type = 94
enter recv_msg_channel_data
length 41
leave recv_msg_channel_data
leave process_packet
check_close: writefd 1, readfd 0, errfd 2, sent_close 0, recv_close 0
writebuf size 41 extrabuf size 0
enter cli_sessionloop
enter writechannel fd 1
FIRST stdout()MESSAGE COMIONG FROM someutil
writechannel wrote 41
leave writechannel
So it seems readfd is set when ran from cgi (using system() call, but
tried other methods too).
Tried also launching same command through crontab, same effect.
>From cgi, tried also to launch remote shell script directly without
using C container (thus dbclient from cgi, same effect).
--
Philippe BRAND
-------------- next part --------------
A non-text attachment was scrubbed...
Name: philippe_brand.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20071205/0a506ae6/attachment.vcf
More information about the Dropbear
mailing list