Mailing List Archive

per-connection sshd doesn't always pass on SIGQUIT
Hey.

I've noticed the following behavior and wondered whether it's possibly
a bug or why it behaves like this:

When having a SSH connection, than it seems there may be two sshd
processes for that, one running as root the other as the user. As far
as I know this is because of privilege separation, like e.g.:
??sshd(2931)???sshd(10174)???bash(10180)
? ??sshd(10000)???sshd(10050,someuser)???sleep(10051)


When sending INT, TERM, QUIT or HUB to the 2nd process (10050), the
first one always exits with and error, and the remote command gets a
HUP when RequestTTY=yes|force or nothing when it's =no.

When sending INT, TERM, QUIT or HUB to the 1st process (10000), than
the second get the same (sent by the 1st) except for the case of QUIT.
Plus the same behavior with the remote command (here sleep) as above,
depending on RequestTTY (but of course, not working in the QUIT case,
as the 2nd process doesn't get that).


Is there any reason why it passes on all these signals but not QUIT?
Or is the perhaps a bug?

Thanks,
Philippe
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
On Tue, 27 Dec 2022, Philippe Cerfon wrote:

> Hey.
>
> I've noticed the following behavior and wondered whether it's possibly
> a bug or why it behaves like this:
>
> When having a SSH connection, than it seems there may be two sshd
> processes for that, one running as root the other as the user. As far
> as I know this is because of privilege separation, like e.g.:
> ??sshd(2931)???sshd(10174)???bash(10180)
> ? ??sshd(10000)???sshd(10050,someuser)???sleep(10051)
>
>
> When sending INT, TERM, QUIT or HUB to the 2nd process (10050), the
> first one always exits with and error, and the remote command gets a
> HUP when RequestTTY=yes|force or nothing when it's =no.
>
> When sending INT, TERM, QUIT or HUB to the 1st process (10000), than
> the second get the same (sent by the 1st) except for the case of QUIT.
> Plus the same behavior with the remote command (here sleep) as above,
> depending on RequestTTY (but of course, not working in the QUIT case,
> as the 2nd process doesn't get that).
>
> Is there any reason why it passes on all these signals but not QUIT?
> Or is the perhaps a bug?

It's because the monitor process doesn't explicitly handle SIGQUIT.
Try this:

diff --git a/monitor.c b/monitor.c
index 93d122e..ea44873 100644
--- a/monitor.c
+++ b/monitor.c
@@ -328,6 +328,7 @@ monitor_child_postauth(struct ssh *ssh, struct monitor *pmonitor)
ssh_signal(SIGHUP, &monitor_child_handler);
ssh_signal(SIGTERM, &monitor_child_handler);
ssh_signal(SIGINT, &monitor_child_handler);
+ ssh_signal(SIGQUIT, &monitor_child_handler);

mon_dispatch = mon_dispatch_postauth20;

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
Hey.

On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm@mindrot.org> wrote:
> It's because the monitor process doesn't explicitly handle SIGQUIT.

Are you going to merge the patch of yours?

Best wishes,
Philippe.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
Philippe Cerfon wrote:
> When having a SSH connection, than it seems there may be two sshd
> processes for that, one running as root the other as the user. As far
> as I know this is because of privilege separation, like e.g.:
> ??sshd(2931)???sshd(10174)???bash(10180)
> ? ??sshd(10000)???sshd(10050,someuser)???sleep(10051)
>
> When sending INT, TERM, QUIT or HUB to the 1st process (10000), than
> the second get the same (sent by the 1st) except for the case of QUIT.
> Plus the same behavior with the remote command (here sleep) as above,
> depending on RequestTTY (but of course, not working in the QUIT case,
> as the 2nd process doesn't get that).
>
> Is there any reason why it passes on all these signals but not QUIT?
> Or is the perhaps a bug?

I don't know the original author's intent with sshd but the main
purpose of the SIGQUIT is to cause the process to dump a core image
for debugging. The core image can then be used to debug the state of
the program. For example if the program appeared to be stuck in an
infinite loop then the core image would allow one to deduce this
mapping the program state back to the program source and allow
inspecting the value of variables at the time.

The traditional name for core was "core". For the most part these
days we set it to be "core.$$" types of names with the process ID in
the file name so that multiple processes would have uniquely named
core files. But on a traditional "core" type of system then the last
one dumped would be the one still left on the file system.

Does it really make sense to pass along SIGQUIT such that instead of
one core file from the program you are targeting with SIGQUIT to get
a debugging core that there would be a chain of core files from each
of the programs where the signal was forwarded to? That doesn't feel
like it makes sense to me. How would that be useful?

Bob

P.S. Note that most systems now have the core ulimit set to disable
writing core dumps to the file system. Because these were often left
due to program bugs that only the developer with source could debug
but that the user did not care about. Meaning that today in order to
obtain a core file these days one must enable the ulimit value of it
first.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
On Thu, 29 Dec 2022, Philippe Cerfon wrote:

> Hey.
>
> On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm@mindrot.org> wrote:
> > It's because the monitor process doesn't explicitly handle SIGQUIT.
>
> Are you going to merge the patch of yours?

Does it solve your problem?

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
Damien Miller wrote:
> Philippe Cerfon wrote:
> > Are you going to merge the patch of yours?
>
> Does it solve your problem?

Was there an actual problem? As I understood it there was no problem
but just the question of why SIGQUIT was different.

I think SIGQUIT should not be passed on because SIGQUIT is different
in that the purpose of it is for debugging to dump a core image and it
does not make sense to pass it along. Adding passing it along would
actually create a bug in that then if used it would cause multiple
processes to dump a core image, all named "core" on traditional
platforms, and the last one dumped would be the one there rather than
the one targeted with the SIGQUIT.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: per-connection sshd doesn't always pass on SIGQUIT [ In reply to ]
On Wed, Jan 11, 2023 at 11:08 PM Damien Miller <djm@mindrot.org> wrote:
> Does it solve your problem?

Well there was no real problem in the strict sense. I've just noticed
that and wondered why in that single case, the child continues to run,
while in all other cases it's terminated, too.

So I thought it would make sense to have consistent behavior.


I don't fully agree with Bob:

If a killed parent process makes it necessary to also kill the child
in the other cases (which AFAIU sshd does manually), then it should be
also done when the parent is killed because of QUIT - or it shouldn't
be necessary in any case.

Whether the child needs to be terminated with QUIT as well, is of
course another topic.


Cheers,
Philippe
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev