OpenSSH 3.6.1p1 on NCR MP-RAS v4.3, several weird terminal problems

[Libove, Jay]

Hi Darren -

Cc: list -

 

There's not much that I can tell you about NCR MP-RAS, other than that
it is a SysV r4.3 derivative, and the hardest UNIX to port to that I've
encountered since my Xenix 286 days.

 

Here is an excerpt from the setsid() manual page:

 

     WARNING

          If the calling process is the  last  member  of  a  pipeline

          started  by  a  job  control  shell,  the shell may make the

          calling process a process group leader.  The other processes

          of  the  pipeline  become  members of that process group. In

          this case, the call to setsid will fail.  For this reason, a

          process  that  calls  setsid  and  expects  to  be part of a

          pipeline should always first fork; the  parent  should  exit

          and  the child should call setsid, thereby insuring that the

          process will work reliably when started by both job  control

          shells and non-job control shells.

 

I noticed in sshpty.c that the call to setsid() follows a section which
will call ioctl(fd, TIOCNOTTY, NULL) #ifdef TIOCNOTTY. Looking in
/usr/include/sys/*.h I find that termios.h and ttold.h #define
TIOCNOTTY.

 

termios.h will only #define TIOCNOTTY if all three of _SYS_TTOLD_H,
_POSIX_SOURCE,  and  _XOPEN_SOURCE  are not defined.

 

ttold.h will only #define TIOCNOTTY if _SYS_TERMIOS_H is not defined.

 

I do see termios.h included in the compile on this platform. I do not
see ttold.h included. Therefore, I assume that the section in sshpty.c
which would call ioctl() with TIOCNOTTY is NOT being executed. I did a
test by commenting out the #ifdef TIOCNOTTY to ensure that the ioctl()
call does happen, and took out the #define STREAMS_PUSH_ACQUIRES_CTTY.
It did not fix the problem, so calling or not calling the ioctl() with
TIOCNOTTY doesn't affect this problem. (Just casting about here).

 

Regarding O_NOCTTY, the man page for open() describes O_NOCTTY as:

 

          O_NOCTTY      If  set  and  the  file  is  a  terminal,  the

                        terminal  will not be allocated as the calling

                        process's controlling terminal.

 

If you have any specific questions regarding the platform, I'm happy to
dig in manual pages, run tests, and report back.

 

-Jay

 

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Wednesday, April 09, 2003 20:18
To: Jay Libove
Cc: openssh-unix-dev at mindrot.org
Subject: Re: OpenSSH 3.6.1p1 on NCR MP-RAS v4.3, several weird terminal
problems

 

Jay Libove wrote: 
> I tried the suggested config.h modification of 
> 
>  #define STREAMS_PUSH_ACQUIRES_CTTY 1 
> 
>  .. and it seems to have fixed all of the problems that I reported
below 
> (^C killing the session, logging out not fully closing the connection,

> lack of job control, and command line pipes being broken). 

        This means that MP-RAS somehow re-acquires a controlling
terminal after 
forking and calling setsid() the first time.  In the Solaris case, a bug

in the pty driver caused it to happen when pushing a STREAMS module 
(hence the #define name).  Linux/glibc5 has the same symptoms but it 
doesn't have STREAMS so it must be acquiring it some other way (not 
honouring O_NOCTTY maybe?) 

        What can you tell us about MP-RAS?  Is it a SysV derivative? 

        Should we just change the define to HAVE_BROKEN_O_NOCTTY.  We
could 
have configure do a run-tine test for it but it'd need a lot of the code

from pty_allocate(). 

-- 
Darren Tucker (dtucker at zip.com.au) 
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69 
    Good judgement comes with experience. Unfortunately, the experience 
usually comes from bad judgement. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030410/76bd5a28/attachment.html