Re: [Sshpass-devel] FW: sshpass at HPUX 11.31

[Shachar S. <sh...@sh...>]

 

Hello Michael, 

I think I understand now. The problem is that, on HPUX, closing all file
descriptors for the controlling TTY disconnect the process. As far as I
can tell, this is a HPUX idiosyncrasy, and is not defined in Posix or,
for that matter, any other Unix whose man page I could lay my hand on. 

Due solely to my curiosity, I wonder whether it is possible to break,
using Ctrl-C, the following (bourne shell) command line: 

$ sleep 20 >/dev/null 2>&1 </dev/null 

On Linux, pressing Ctrl-C aborts the sleep. Does it do so on HPUX? 

I'll try to get a patch out to you in the coming couple of days. 

Thanks,
Shachar 

On 01/11/2017 17:10, LI Michael wrote: 

> Hi Shemesh, 
> 
> Thank you very much for your reply. 
> 
> I've forwarded your analysis to HP support, 
> 
> Based on their suggestions, I've done some tests, still no luck. 
> 
> Please see the mail I sent to HP support. 
> 
> Thanks and regards. 
> 
> Michael Li 
> 
> SWIFT | Security Infrastructure, Messaging Solutions
> Tel: +1 703 365 6136
> www.swift.com [1]
> 
> This e-mail and any attachments thereto may contain information which is confidential and/or proprietary and intended for the sole use of the recipient(s) named above. If you have received this e-mail in error, please immediately notify the sender and delete the mail. Thank you for your co-operation. SWIFT reserves the right to retain e-mail messages on its systems and, under circumstances permitted by applicable law, to monitor and intercept e-mail messages to and from its systems. 
> 
> FROM: LI Michael 
> SENT: Wednesday, November 01, 2017 10:57 AM
> SUBJECT: RE: [Sshpass-devel] sshpass at HPUX 11.31 
> 
> Hi Fluyt, 
> 
> Thank you very much for your suggestions. 
> 
> I have done the various combinations, no luck. 
> 
> Please see the testing results below. Any suggestions? 
> 
> COMMENTED OUT 
> 
> RESULTS 
> 
> ERROR MESSAGE 
> 
> TUSC FILE 
> 
> close( slavept );
> close( masterpt ); 
> 
> Failed 
> 
> read_passphrase: can't open /dev/tty: No such device or address 
> 
> tusc.out_close_slavept_masterpt 
> 
> setsid();
> close( slavept );
> close( masterpt ); 
> 
> Failed 
> 
> debug2: input_userauth_info_req: num_prompts 1
> Password: Abcd1234
> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
> Read from socket failed: Connection reset by peer 
> 
> tusc.out_setsid_close_slavept_masterpt 
> 
> setsid(); 
> 
> Success(*) 
> 
> debug2: input_userauth_info_req: num_prompts 1
> Password: Abcd1234
> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
> ...
> Wed Nov 1 13:47:41 GMT 2017
> ...
> debug1: Exit status 0 
> 
> tusc.out_setsid 
> 
> setsid();
> close( slavept ); 
> 
> Success(*) 
> 
> debug2: input_userauth_info_req: num_prompts 1
> Password: Abcd1234
> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
> ...
> Wed Nov 1 13:50:35 GMT 2017
> ...
> debug1: Exit status 0 
> 
> tusc.out_setsid_close_slavept 
> 
> setsid();
> close( masterpt ); 
> 
> Success(*) 
> 
> debug2: input_userauth_info_req: num_prompts 1
> Password: Abcd1234
> debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
> ...
> Wed Nov 1 13:52:51 GMT 2017
> ...
> debug1: Exit status 0 
> 
> tusc.out_setsid_close_masterpt 
> 
> Success(*) means that even though get the correct date back, I have to type password interactively, unable to exit the process in the end, it must be killed by using "kill" command. 
> 
> /tmp/mli/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Abcd1234 ssh -vvv nledfd02 date" 
> 
> $ cat /tmp/mli/tusc.ksh 
> 
> /usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1 
> 
> For the tusc files, please see the attached sshpass_tusc.z_ip. 
> 
> _C:CSharedSSHLitesshpass>unzip -l sshpass_tusc.zip_ 
> 
> _Archive: sshpass_tusc.zip_ 
> 
> _ Length Date Time Name_ 
> 
> _--------- ---------- ----- ----_ 
> 
> _ 1458612 11/01/2017 09:20 tusc.out_close_slavept_masterpt_ 
> 
> _ 1498879 11/01/2017 09:47 tusc.out_setsid_ 
> 
> _ 1498255 11/01/2017 09:52 tusc.out_setsid_close_masterpt_ 
> 
> _ 1498549 11/01/2017 09:50 tusc.out_setsid_close_slavept_ 
> 
> _ 1450065 11/01/2017 09:44 tusc.out_setsid_close_slavept_masterpt_ 
> 
> _--------- -------_ 
> 
> Thanks and regards. 
> 
> Michael Li 
> 
> SWIFT | Security Infrastructure, Messaging Solutions
> Tel: +1 703 365 6136
> www.swift.com [1]
> 
> This e-mail and any attachments thereto may contain information which is confidential and/or proprietary and intended for the sole use of the recipient(s) named above. If you have received this e-mail in error, please immediately notify the sender and delete the mail. Thank you for your co-operation. SWIFT reserves the right to retain e-mail messages on its systems and, under circumstances permitted by applicable law, to monitor and intercept e-mail messages to and from its systems. 
> 
> FROM: Fluyt, Andre 
> SENT: Wednesday, October 25, 2017 8:35 AM
> TO: LI Michael
> 
> SUBJECT: RE: [Sshpass-devel] sshpass at HPUX 11.31 
> 
> ----------------------------------------------------------------------------- 
> This message originates from outside our organisation. Please be 
> extra vigilant before you click on a link, open attachments or reply. 
> ----------------------------------------------------------------------------- 
> 
> Hi Michael, 
> 
> Thanks. At least I can now see the exact same symptom as you observed. 
> 
> Reading the comment in the source, it looks like the developer has struggled getting the tty as controlling terminal working. 
> 
> There is a piece of source code that I don't understand the logic of. 
> 
> _..._ 
> 
> _int childpid=fork();_ 
> 
> _ if( childpid==0 ) {_ 
> 
> _ // Child_ 
> 
> _ _ 
> 
> _ // Detach us from the current TTY_ 
> 
> _ setsid();_ 
> 
> _ // This line makes the ptty our controlling tty. We do not otherwise need it open_ 
> 
> _ slavept=open(name, O_RDWR );_ 
> 
> _ close( slavept );_ 
> 
> _ _ 
> 
> _ close( masterpt );_ 
> 
> _...._ 
> 
> _ _ 
> 
> _ _ 
> 
> This results in this tusc trace output : 
> 
> ... 
> 
> fork() ....................................................................................... = 13356 
> 
> fork() .................................................... (returning as child ...) ......... = 13354 
> 
> setpgrp3(2) .................................................................................. = 13356 
> 
> open("/dev/pts/0", O_RDWR|O_NOCTTY, 024700) .................................................. = 6 
> 
> open("/dev/pts/0", O_RDWR, 01210) ............................................................ = 6 
> 
> sigprocmask(SIG_SETMASK, 0x7ffff0c0, NULL) ................................................... = 0 
> 
> close(6) ..................................................................................... = 0 
> 
> close(4) ..................................................................................... = 0.. 
> 
> Now, if we look at the documentation : 
> 
> The Controlling Terminal A terminal can belong to a process as its controlling terminal. Each process of a session that has a controlling terminal has the same controlling terminal. A terminal can be the controlling terminal for at most one session. The controlling terminal for a session is allocated by the session leader. If a session leader has no controlling terminal and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open(2), the terminal becomes the controlling terminal of the session and the controlling terminal's foreground process group is set to the process group of the session leader. While a controlling terminal is associated with a session, the session leader is said to be the controlling process of the controlling terminal. The controlling terminal is inherited by a child process during a fork() (see fork(2)). A process relinquishes its controlling terminal if it creates a new session with setsid() or
setpgrp() (see setsid(2) and setpgrp(2)), or when all file descriptors associated with the controlling terminal have been closed. When the controlling process terminates, the controlling terminal is disassociated from the current session, allowing it to be acquired by a new session leader. A SIGHUP signal is sent to all processes in the foreground process group of the controlling terminal. Subsequent access to the terminal by other processes in the earlier session can be denied (see Terminal Access Control) with attempts to access the terminal treated as if a modem disconnect had been sensed. 
> 
> So, the child does a 'setsid()' call which creates a new session and makes the child the session group leader, thereby relinquishing the controlling terminal. 
> 
> The developer states that the line : "_slavept=open(name, O_RDWR );" _should make the tty the controlling terminal for the child process. 
> 
> Ok, fair enough, but why does he then immediately close the slavept & masterpt ? 
> 
> See the yellow highlights in the documentation paragraph. 
> 
> What I would suggest is that you recompile without the closing of slavept & masterpt in the child process. See if that works. 
> 
> Also, I don't understand why we need to detach from the TTY by doing setsid(). Another test could be to leave out the setsid() call. Normally a child process inherits the controlling terminal from its parent. 
> 
> Best regards. 
> 
> Andre Fluyt
> Technical Account Manager
> Customer Solution Center
> 
> FROM: Shachar Shemesh [mailto:sh...@sh...] 
> SENT: Sunday, September 03, 2017 10:07 AM
> TO: LI Michael
> CC: SSHPass Development
> SUBJECT: Re: [Sshpass-devel] sshpass at HPUX 11.31 
> 
> ----------------------------------------------------------------------------- 
> This message originates from outside our organisation. Please be 
> extra vigilant before you click on a link, open attachments or reply. 
> ----------------------------------------------------------------------------- 
> 
> On 02/09/17 00:39, LI Michael wrote: 
> 
> Hi Shemesh, 
> 
> Thank you very much for your reply. 
> 
> Please see the attached tusc output, tusc.out. 
> 
> I ran the command as follows : 
> 
> _test1@host1234 [/home/test1] $/tmp/tusc/tusc.ksh "/tmp/sshpass/sshpass-1.06/sshpass -p Xyza1234 ssh -vvv host1234 date"_ 
> 
> _ _ 
> 
> _root@host1234 [/tmp/tusc]_ 
> 
> _# cat tusc.ksh_ 
> 
> _/usr/contrib/bin/tusc -a -e -k -E -f -F -h -l -n -p -r all -R -T -u -v -w all -o /tmp/tusc/tusc.out $1_ 
> 
> _ _ 
> 
> Thanks and regards. 
> 
> Michael Li 
> 
> Here's what I see in the traces you sent me:
> 
> -u [/tmp/sshpass][14066]{3783827} fork() ................... (returning as child ...) ......... = 14064 {3783821}
> 
> The child process is 14066.
> 
> -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. [entry]
> -u [/tmp/sshpass][14066]{3783827} setpgrp3(2) ................................................. = 14066
> 
> Start a new session, disconnecting from the previous TTY
> 
> -u [/tmp/sshpass][14066]{3783827} open(0x400132d0, O_RDWR, 01210) ............................. [entry]
> -u [/tmp/sshpass][14066]{3783827} open("/dev/pts/5", O_RDWR, 01210) ........................... = 6
> 
> Open /dev/pts/5 with the flags O_RDWR. According to Posix, at this point pts/5 is supposed to become the controlling terminal for the new process. This, obviously, does not happen.
> 
> At this point I need to return the responsibility to this problem to you. As far as I can tell, the process is not behaving the way it should. I have no tools for investigating this any further than that.
> 
> If you can find out why opening a TTY device does not turn it into the controlling TTY of the process, please do let me know, and I can work that into sshpass.
> 
> Shachar

 

Links:
------
[1] http://www.swift.com/