[Bug 3435] New: mux process command lines contains many 0x0

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3435

            Bug ID: 3435
           Summary: mux process command lines contains many 0x0
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

I just noted something odd.

What I do is, construct (in a shell script) and execute a ssh command,
which some (constructed) options set and executes an (also constructed
and quite long) remote shell command.

When I do this on a connection for which I have control channel muxing
set up, the [mux] process gets very long cmdline.

The following is, when the (initiating) ssh command is still running:
$ ps ax | grep ssh
   4712 ?        Ss     0:00 /usr/bin/ssh-agent
cinnamon-session-cinnamon
 543871 pts/18   S+     0:00 ssh -o ClearAllForwardings=yes -o
ForwardAgent=no -o ForwardX11=no -o ForwardX11Trusted=no -o
GatewayPorts=no -o PermitLocalCommand=no -o PermitRemoteOpen=none -o
UpdateHostKeys=no -o BatchMode=yes foo.grid.lrz.de set -e              
  unset -v IFS                 export PATH='/usr/bin:/bin'             
   export LC_ALL='C'                 cd / sleep 400                    
            p="/tmp/x509up_u$(id -u)"                                
t="$(mktemp)"                 {                 ?cat >"${t}"  &&       
         ?mv -f --no-target-directory "${t}" "${p}"                 }  
||   { rm -f "${t}"  &&  exit 10  ||  exit 20; }                 ?     
          { ?                ?m="$(stat --printf='%Y' "${p}")"  && ?   
            ?h="$(sha256sum "${p}")"  && ?                ?{ [ -n
"${p##*\'*}" ]  &&  [ -n "${m##*\'*}" ]  &&  [ -n "${h##*\'*}" ]; }  
&& ?                ? ?                ?printf 'if [ "$(stat
--printf='\''%%Y '\'' '\''%s'\''; sha256sum '\''%s'\'')"  =  '\''%s
%s'\'' ]; then\n\trm -f '\''%s'\'';\nfi\n' "${p}" "${p}" "${m}" "${h}"
"${p}"  | ?                ?env -i PATH="${PATH}" LC_ALL="${LC_ALL}"  ?
               ?at -M 'now + 3 minutes' 2>&1 ?                }   ||  
{ rm -f "${p}"  &&  exit 11  ||  exit 21; } ?               
 543876 ?        Ss     0:00 ssh:
/home/calestyo/.ssh/mux/root at foo.grid.lrz.de:22 [mux]                   
 543888 pts/19   S+     0:00 grep --color=auto ssh

It probably cannot be seen well in bugzilla, but after the [mux]
process there are numerous empty lines (actually just the spaces after
the command).

Once the initiating ssh is Ctrl-C'ed:
$ ps ax | grep ssh
   4712 ?        Ss     0:00 /usr/bin/ssh-agent
cinnamon-session-cinnamon
 543689 pts/20   S+     0:00 vi bin/ssh_killall-mux
 543876 ?        Ss     0:00 ssh:
/home/calestyo/.ssh/mux/root at foo.grid.lrz.de:22 [mux]                   
 544406 pts/19   S+     0:00 grep --color=auto ssh

again, with loads of empty lines.

 hd /proc/543876/cmdline 
00000000  73 73 68 3a 20 2f 68 6f  6d 65 2f 63 61 6c 65 73  |ssh:
/home/cales|
00000010  74 79 6f 2f 2e 73 73 68  2f 6d 75 78 2f 72 6f 6f 
|tyo/.ssh/mux/roo|
00000020  74 40 6c 63 67 2d 6c 72  7a 2d 61 64 6d 69 6e 2e 
|t@*privacy* foo.|
00000030  67 72 69 64 2e 6c 72 7a  2e 64 65 3a 32 32 20 5b 
|grid.lrz.de:22 [|
00000040  6d 75 78 5d 00 00 00 00  00 00 00 00 00 00 00 00 
|mux]............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
*
00000500  00 00 00 00 00 20 00                              |..... .|
00000507


That may be quite annoying  for anyone who e.g. uses pgrep to kill mux
processes and expects the name to end after the "]" ;-)


And another odd thing (please tell whether this is expected or not,
cause then I'd open a new ticket):

You've noticed the sleep 400 in my remote command (which was just there
fore debugging)?

Even when I Ctrl-C the (mux-initiating) ssh right after the start, the
[mux] process lingers around for those 400+ControlPersist seconds.
Well not exactly those it actually differs a few seconds... (which I
found also a bit add).


Shouldn't ControlPersist "start to count" when the last connection is
gone and shouldn't that happen with the Ctrl-C?


Thanks,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.