sslh does not detach properly, when started

[ftasnetamot]

As I am currently working on improvements of my servers configuration, I realized another problem.
I am starting sslh now on systemd-free systems, via the sysv-init /etc/initd.d/sslh start script.
And when I restart sslh from a terminal after a configuration change, I get status messages messages from sslh written into my terminal window.
When researching this close, I figured out, that there is a debian-bug pending since 2019, describing the same issue. Systemd users are not aware of this, as systemd catches all output from stdout and stderr.
The discussion in the debian bug-report seems not to find the cause, as one of the discussionists couldn't reproduce. So i started myself some research, I wished to share.

First of all, I think, that finally a code change may appropriate, as a daemon should detach from stdout/stdin/stderr, when backgrounding.
The connections should stay connected, when started with the -f parameter.

But now my findings:
On a system without systemd (devuan), the filehandles of sslh are looking like:

ls -lad /proc/801[89]/fd/* 
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8018/fd/0 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8018/fd/1 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8018/fd/2 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8018/fd/3 -> 'socket:[133981]'
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8019/fd/0 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8019/fd/1 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8019/fd/2 -> /dev/pts/1
lrwx------ 1 root root 64 16. Aug 13:35 /proc/8019/fd/3 -> 'socket:[133981]'

So, this fits to my observation, why I get my terminal messed up. Thankfully I can get rid of it, when using the --background parameter in the startup script, as also mentioned in the debian bug report. When doing this the output looks like:

ls -lad /proc/1397[89]/fd/* 
lr-x------ 1 root root 64 16. Aug 13:31 /proc/13978/fd/0 -> /dev/null
l-wx------ 1 root root 64 16. Aug 13:31 /proc/13978/fd/1 -> /dev/null
l-wx------ 1 root root 64 16. Aug 13:31 /proc/13978/fd/2 -> /dev/null
lrwx------ 1 root root 64 16. Aug 13:31 /proc/13978/fd/3 -> 'socket:[183504]'
lr-x------ 1 root root 64 16. Aug 13:31 /proc/13979/fd/0 -> /dev/null
l-wx------ 1 root root 64 16. Aug 13:31 /proc/13979/fd/1 -> /dev/null
l-wx------ 1 root root 64 16. Aug 13:31 /proc/13979/fd/2 -> /dev/null

And the terminal stays clean.

OK, Now I have researched my old systemd servers. When sslh is started via systemctl (and without the --background parameter) the output looks like:

ls -lad /proc/921/fd/* /proc/107682/fd/*
lr-x------ 1 sslh sslh 64 Aug 16 13:43 /proc/107682/fd/0 -> /dev/null
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/107682/fd/1 -> 'socket:[24226]'
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/107682/fd/2 -> 'socket:[24226]'
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/107682/fd/3 -> 'socket:[849757]'
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/107682/fd/4 -> 'socket:[850519]'
lr-x------ 1 sslh sslh 64 Aug 16 13:43 /proc/921/fd/0 -> /dev/null
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/921/fd/1 -> 'socket:[24226]'
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/921/fd/2 -> 'socket:[24226]'
lrwx------ 1 sslh sslh 64 Aug 16 13:43 /proc/921/fd/3 -> 'socket:[24340]'

which shows, that systemd grabs stdin/stdout to one socket and stderr to another (log?) socket.

But on most systems, I was under the impression, that I have removed the systemd dependancy, by the following steps:

• Creating a symlink /lib/systemd/system/sslh pointing to /dev/null
• Deleting /var/lib/systemd/deb-systemd-helper-enabled/sslh.service.dsh-also
• Deleting /etc/systemd/system/sslh.service.d
• Deleting /etc/systemd/system/sslh-transparent.service
• Deleting /etc/systemd/system/multi-user.target.wants/sslh-transparent.service
• Deleting /etc/systemd/system/multi-user.target.wants/sslh.service

But when I do a /etc/init.d/sslh restart, the output still tells me, that it is started using systemctl. Even, when I followed all advices, how to untie an application from systemd.
The output tells me: Restarting sslh (via systemctl): sslh.service, however there is not a single connection piece left, which ties this to systemd. And the output still looks like:

ls -lad /proc/34269/fd/* /proc/34270/fd/*
lr-x------ 1 root root 64 Aug 16 13:59 /proc/34269/fd/0 -> /dev/null
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34269/fd/1 -> 'socket:[628846]'
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34269/fd/2 -> 'socket:[628846]'
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34269/fd/3 -> 'socket:[629791]'
lr-x------ 1 root root 64 Aug 16 13:59 /proc/34270/fd/0 -> /dev/null
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34270/fd/1 -> 'socket:[628846]'
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34270/fd/2 -> 'socket:[628846]'
lrwx------ 1 root root 64 Aug 16 13:59 /proc/34270/fd/3 -> 'socket:[629791]'

And now I create another file in my root users home-directory, sslh.sh, which contains:

#!/bin/bash
. /etc/init.d/sslh

And I do now a ./sslh.sh restart, which is nothing different than the previous one, but I don't do that from the /etc/init.d location!
And now I receive the expected message from my startup-script:

* Restarting ssl/ssh multiplexer sslh

and now also here I get unwanted output to the terminal, and I see, that nobody has grabbed the filehandles:

ls -lad /proc/3443[34]/fd/*
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34433/fd/0 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34433/fd/1 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34433/fd/2 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34433/fd/3 -> 'socket:[629415]'
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34434/fd/0 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34434/fd/1 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34434/fd/2 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 16 14:05 /proc/34434/fd/3 -> 'socket:[629415]'

So I have learned, that systemd is still grabbing sysv-init-scripts, just because they are located in /etc/init.d. This was a real important finding, as I learned, that you can't easily escape from systemd.

So my current impression is, that a code-change would make sslh behave much better as a daemon, even when there are workarounds available (--background parameter, systemd grabbing output). In other systems this behaviour still could lead to problems.

I see this issue as an close relative to #419. As I am also very interested in getting a most up-to-date debian package (as this is the mother of ubuntu/devuan and many others), I think, its worth to look at those bug-reports and get things straight.
There is another debian bug-report, which contains an patch, but I had no deeper look into that.

I see this behaviour as a minor security breach, as this failure may reveal information to others, as the output is tied to the terminal-id.
When a restricted user connects to an system, where an admin has restarted sslh, and this user gets the same terminal-id, he gets the messages.

I may propose a PR for the detaching in the next days, if there are no other idea.

[ftasnetamot]

as my PR was merged, this issue is solved.