Is this a bug? 2: the return

[Philippe Brand]

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