openssh unix dev - Aug 2018 - trying to resurrect discussion about "Cannot signal a process over a channel (rfc 4254, section 6.9)"

Hi,
>>> It would be nice to know what the precise technical issues are that
have
>>> prevented support for this from being added. From what I recall, it
>>> seemed like the delay was largely due to details of the client
>>> behaviour, and possibly some feature creep. 

It would indeed be really great to have some details on this point.

Concerning the test of the server side feature, it should be pretty similar to
the test of the functionality of the ~B escape character !
Unfortunately, I was unable to find any reference that such a test exists : is
anyone aware of where it could be ?

Moreover, is there any kind of guideline concerning the environment that should
be use for the test suite ?

Also in the RFC it is said :?Some systems may not implement signals, in which
case they SHOULD ignore this message? . So I think the proposed patch should
have some kind of whitelisting.

 Thanks in advance for the answers,

Yonathan Bleyfuesz

> On 6 Jul 2018, at 00:19, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> 
> On Thu, Jul 05, 2018 at 23:42:55 +0200, Thierry Parmentelat wrote:
>> 
>>> At one point, I had wondered about separating out the client and
server
>>> support as well. At first glance, that would seem to help move
things
>>> forward and would address most of the reported use cases. However,
I
>>> have some users who would need the client support as well.
>>> 
>>> I suspect that adding the server support first might be a problem
for
>>> the developers. Such a feature would need regression and unit
tests, and
>>> those would be easier to implement if the client has support for
the
>>> feature.
>> 
>> Fair enough, but apparently having to swallow both aspects in the same
move seems to have proven too big a bite at least once :)
>> I am not at all familiar with the openssh codebase, but if that helps
and if that sounds like a doable idea, we can certainly propose to provide some
dedicated test stubs addressing the server side, written e.g. in asynchronous
python based on asyncssh, that at first sight has all that is needed to carry
out fine-grained tests in this area; even if temporarily, i.e. until some
agreement can be found on what the client side should look like
>> 
>>> It would be nice to know what the precise technical issues are that
have
>>> prevented support for this from being added. From what I recall, it
>>> seemed like the delay was largely due to details of the client
>>> behaviour, and possibly some feature creep. 
>> 
>> agreed ! the initial thread was not exactly very talkative on all
this..
>> 
> 
> One thing to keep in mind is that OpenSSH is primarily developed on
> OpenBSD. Any test suite would need to work on a base OpenBSD install,
> which does not include Python. Of course, the test suite would need to
> work on other platforms as well.
> 
> -- 
> Iain Morgan

Hi all,

I would like to propose some ideas to revivify this subject.

-First, we could add support on the client to send signal thanks to the escape
characters.
(code :
https://github.com/JawaGL/openssh-portable/commit/5bc9e6bc959b1b0f89d7ca7b4b04d7c37079fef0
).

With this, in order to send a message requesting the server to send a SIGTERM to
the remote process, you need to type  ?~ST? which is not really invasive
client-side.

But this means that the client has to enable TTY.


-Secondly , server-side, there is a problem with the currently suggested patch :
it only works when we do an ?exec? request to the server (eg : ssh some-host
?some; commands;?).

This is because in the other possible configuration, a shell is launched by the
server. Then when we launch a process, it is forked by this shell and thus it
has its own group-id.

When the user launches a signal-request hoping to reach a blocking process, the
pid that is used by the ?killpg? function is the one of the shell. So it is this
shell that catches the signal resulting in it:
	- dying and leaving zombies 
	- dying and taking its child with him (SIGHUP and SIGKILL)
	- ignoring the signal (SIGINT, SIGTERM, SIGQUIT).

Example of ID?s when I connect to a server and launch the script test_signal.sh
:
 PID   PPID  PGID  SID
 4060  1598  4060  1556 sshd            sshd: root at pts/2
 4062  4060  4062  4062 bash            -bash
 4075  4062  4075  4062 sh              sh test_signal.sh
 4076  4075  4075  4062 sh              sh test_signal.sh

So in order to take this use case into account we could use the
'tcgetpgrp()?  function from ?unistd.h?.
(code :
https://github.com/JawaGL/openssh-portable/commit/3667c0d90688c43ac0729083f73afa65102226b4
)

Of course this would still work if there are no TTY present since we can still
access the PGID of the forked child in the session attributes.

-Finally, in order to test these functionalities, we could integrate a test case
in the regress folder. (code :
https://github.com/JawaGL/openssh-portable/commit/02c39b15363c54d0e622e5724c721a474e1cacd6).


I tested all these features on MacOSX and Ubuntu 18.

I hope this helps,
Thanks in advance for your returns,

Yonathan

FWIW, now that privsep is mandatory I have no objection to including
signal support in sshd.

On Wed, 25 Jul 2018, Yonathan Bleyfuesz wrote:
> Hi all,
> 
> I would like to propose some ideas to revivify this subject.
> 
> -First, we could add support on the client to send signal thanks to the
escape characters.
> (code :
https://github.com/JawaGL/openssh-portable/commit/5bc9e6bc959b1b0f89d7ca7b4b04d7c37079fef0
).
> 
> With this, in order to send a message requesting the server to send a
SIGTERM to the remote process, you need to type  ?~ST? which is not really
invasive client-side.
> 
> But this means that the client has to enable TTY.
> 
> 
> -Secondly , server-side, there is a problem with the currently suggested
patch : it only works when we do an ?exec? request to the server (eg : ssh
some-host ?some; commands;?).
> 
> This is because in the other possible configuration, a shell is launched by
the server. Then when we launch a process, it is forked by this shell and thus
it has its own group-id.
> 
> When the user launches a signal-request hoping to reach a blocking process,
the pid that is used by the ?killpg? function is the one of the shell. So it is
this shell that catches the signal resulting in it:
> 	- dying and leaving zombies 
> 	- dying and taking its child with him (SIGHUP and SIGKILL)
> 	- ignoring the signal (SIGINT, SIGTERM, SIGQUIT).
> 
> Example of ID?s when I connect to a server and launch the script
test_signal.sh :
>  PID   PPID  PGID  SID
>  4060  1598  4060  1556 sshd            sshd: root at pts/2
>  4062  4060  4062  4062 bash            -bash
>  4075  4062  4075  4062 sh              sh test_signal.sh
>  4076  4075  4075  4062 sh              sh test_signal.sh
> 
> So in order to take this use case into account we could use the
'tcgetpgrp()?  function from ?unistd.h?.
> (code :
https://github.com/JawaGL/openssh-portable/commit/3667c0d90688c43ac0729083f73afa65102226b4
)
> 
> Of course this would still work if there are no TTY present since we can
still access the PGID of the forked child in the session attributes.
> 
> -Finally, in order to test these functionalities, we could integrate a test
case in the regress folder. (code :
https://github.com/JawaGL/openssh-portable/commit/02c39b15363c54d0e622e5724c721a474e1cacd6).
> 
> 
> I tested all these features on MacOSX and Ubuntu 18.
> 
> I hope this helps,
> Thanks in advance for your returns,
> 
> Yonathan
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>