Hi,

molly-guard fails to detect an ssh session when run from within an active
screen.

I guess this is because of (30-query-hostname):

    PTS=$(readlink /proc/$$/fd/0)
    if ! pgrep -f "^sshd.+${PTS#/dev/}\>" >/dev/null \
    && [ -z "${SSH_CONNECTION:-}" ]; then

PTS will point to something that pgrep can not find.

We could check for $STY to test if inside screen or not, but no idea how to
proceed from there.

OTOH I don't understand the need for the pgrep-voodoo anyway, why not simply
check for ! -z $SSH_CONNECTION?

regards

	Stefan

also sprach bd@bc-bd.org <bd@bc-bd.org> [2009.10.25.1506 +0100]:

Right, as documented in the manpage.

Neither do I. If you have ideas, or maybe a new test scriptlet, I'd
love to hear them.

Because sudo resets the environment.

also sprach bd@bc-bd.org <bd@bc-bd.org> [2009.10.25.1506 +0100]:

Right, as documented in the manpage.

Neither do I. If you have ideas, or maybe a new test scriptlet, I'd
love to hear them.

Because sudo resets the environment.

martin f krafft wrote:

attached.

doh.

Stefan Völkel wrote:

well, one debug statement made it through, corrected patch attached.

Hi,

after playing around with this, it looks like this will only work as
long as the screen session has not been detached.

Before detaching the screen session it looks like this in ps fax:

 2580 ?        Ss     0:00 /usr/sbin/sshd
 3568 ?        Ss     0:00  \_ sshd: bd [priv]
 3570 ?        S      0:03      \_ sshd: bd@pts/0
 3571 pts/0    Ss     0:00          \_ -bash
 4982 pts/0    S+     0:00              \_ screen -U -S work ...
 4983 ?        Ss     0:00                  \_ SCREEN -U -S work ...
 4984 pts/1    Ss+    0:00                      \_ ssh  ***
 4985 pts/2    Ss+    0:00                      \_ ssh ***
 4986 pts/3    Ss     0:00                      \_ bash
 5025 pts/3    R+     0:00                          \_ ps fax
 5026 pts/3    S+     0:00                          \_ less

After a detach/attach it looks like this:

 2580 ?        Ss     0:00 /usr/sbin/sshd
 3568 ?        Ss     0:00  \_ sshd: bd [priv]
 3570 ?        S      0:03      \_ sshd: bd@pts/0
 3571 pts/0    Ss     0:00          \_ -bash
 5031 pts/0    S+     0:00              \_ screen -Udr work
 ...
 4983 ?        Ss     0:00 SCREEN -U -S work ...
 4984 pts/1    Ss+    0:00  \_ ssh ***
 4985 pts/2    Ss+    0:00  \_ ssh ***
 4986 pts/3    Ss     0:00  \_ bash
 5033 pts/3    R+     0:00      \_ ps fax
 5034 pts/3    S+     0:00      \_ less

Now if you run molly-guard from bash (PID 4986) it will walk up the
process hierarchy and _NOT_ encounter ssh, since SCREENs parent is now init.

I changed the patch to walk up the process hierarchy and molly-guard the
machine if screen or sshd is found.

regards

	Stefan

tags 552321 help moreinfo
thanks

also sprach Stefan Völkel <bd@bc-bd.org> [2009.12.11.0029 +1300]:
[…]
direction of a hack (if molly-guard isn't a giant hack already).

I was thinking that we should take a different approach: prompt
UNLESS we can verify that the current tty is local. Any ideas how to
accomplish that?

I guess one could patch /sbin/halt to accept a --hostname parameter:

root@foo $ /sbin/halt --hostname bar
E: dude, no, wrong machine.

Well, this feels to me like trying to prove a negative, which is always hard or
impossible.

The current approach, hackish or not, does state pretty clear what it does do and
what not. If you run molly-guarded halt from a screen or ssh session it will ask
you for the hostname you want to shutdown.

I think this burns down to, what is it that molly-guard is trying to acomplish?

  a) Should it protect you from shuting down a/the wrong _remote_ machine?

or

 b) Should  it protect you from shuting down _the wrong_ machine?

If a), well it fails when ssh is run from screen, which makes it unusable at
least for me, because it provides me with a false feeling of security.

If b), then it's more of a --hostname approach.

HTH

	Stefan

also sprach bd@bc-bd.org <bd@bc-bd.org> [2010.02.01.2237 +1300]:

Think about a firewall: there, you'd configure it to REJECT all
packages it does not ACCEPT. So why should molly-guard not be
equally careful and REJECT (ask for confirmation) everything except
when it knows for sure that it can ACCEPT (continue without
confirmation)?

(b) is already handled with ALWAYS_QUERY_HOSTNAME.

As I see it, a Firewall tests for the presence of things (certain port, IP,
protocol, etc) molly-guard tests for the absence of things (ssh ENV, etc).

Now, to get back to what this bug was originally about.

I still think the patch is a valuable addition to molly-guard, as it fixes a
problem I and maybe others have. I think that holding this patch back because
you feel molly-guard needs to be rewritten is the wrong thing to do.

regards

	Stefan

also sprach bd@bc-bd.org <bd@bc-bd.org> [2010.02.03.0021 +1300]:

Molly-guard currently tests to see if it runs remotely. Previously,
this was done with $SSH_CONNECTION, but now it checks for the PTY of
the sshd daemon, which is not checking for absence.

I'll take another look today.

also sprach bd@bc-bd.org <bd@bc-bd.org> [2010.02.03.0021 +1300]:

There is no reason for me *not* to include it, so I will.

However, there is one remaining problem, as far as I can see. While
your patch gets rid of the pgrep-based approach and hence solves the
kFreeBSD-problem, where the tty-name of the sshd process is not
exported by ps, it introduces another Linux-ism:

  EXE=$(basename $(readlink /proc/$PARENT/exe) )

/proc/$PARENT/exe does not exist on FreeBSD. Can you fathom another
way to achieve this?

Great :).

Since I don't have a kfreebsd machine I asked in irc.debian.org/#debian-kbsd,
where I have been told that kfreebsd normally does have /proc mounted and the
exe link exists.

We discovered one bash-ism, but the test for /proc/$PID/exe worked.

Attached is an updated version of the patch fixing said bash-ism.

regards

	Stefan

Hi,

What's up with #55231 ?

I have a similar issue with use of molly-guard in a tmux session.

If you take a decision which leads to a final patch, I would be glad to
test it with tmux.

Regards,

also sprach Philippe Basinska <philippe@basinska.fr> [2012.01.24.2122 +0100]:

What about the last patch in the bug report?

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=67;filename=screen.patch;att=1;bug=552321

Le 24/01/2012 22:19, martin f krafft a écrit :

server-bl:~# halt
I: molly-guard: tmux found.
Please type in hostname of the machine to halt:

I let you decide what is better for molly-guard (concerning to the
previous messages in this bug report). Whatever, the patch is good
enough to fix the issue.

See you,

Hello!

I've just uploaded a new version of molly-guard (0.4.5-1); my intention
was to close the release critical bug #548099, so I focused on letting
molly-guard work on Debian GNU/kFreeBSD with the same set of
functionalities as the previous version, rather than adding new
features.

Mine was meant to be a small and non-intrusive non-maintainer upload (as
the author and maintainer is Martin), but I got a sort of field
promotion ;-) and uploaded it as a co-maintainer.

So: your work has been ignored in this release (including the "look for
a sshd parent" part, which is in 0.4.5-1 as well but with a different
implementation) just because the aim was to get rid of a RC bug.

I see that you and Martin already discussed (and I'd personally
appreciate some support for screen/tmux) so I'd prefer to leave to him
the choice of adding non-ssh support to molly-guard, unless I receive an
explicit authorization to do so on his behalf. :-)

In any case, thanks for your contribution!

Ludovico