Mailing List Archive

On Wed, Mar 31, 2021 at 12:33:43AM +0200, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Hello!
>
> I just stumbled over the fact that the ControlMaster process does
> not do "cd /" but remains where the ssh client was invoked. Is
> this intentional, or should i open a bug report on that?
>
> [snip]
>
> Thanks, and Ciao! from Germany,
>
> --steffen

Hi,

I reported this too a little while ago and there was no
interest. But it is a pain when your cwd is a USB stick
that you want to umount. I've created a pull request
that fixes it:

https://github.com/openssh/openssh-portable/pull/239

But it's failing checks on 4 Ubuntu kitchensink/sk
versions.

This page shows the error message:

https://github.com/openssh/openssh-portable/actions/runs/704178803

No files were found with the provided path:
regress/*.log regress/valgrind-out/. No artifacts
will be uploaded.

Does anyone know if the tests can/should be altered to cope with
chdir / having been introduced?

cheers,
raf

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

Hello!

raf wrote in
<20210331075157.sgfbkvofdx6dgiyi@raf.org>:
|On Wed, Mar 31, 2021 at 12:33:43AM +0200, Steffen Nurpmeso <steffen@sdao\
|den.eu> wrote:
|> I just stumbled over the fact that the ControlMaster process does
|> not do "cd /" but remains where the ssh client was invoked. Is
|> this intentional, or should i open a bug report on that?
|>
|> [snip]
...
|I reported this too a little while ago and there was no
|interest. But it is a pain when your cwd is a USB stick
|that you want to umount. I've created a pull request

Yeah, and encrypted volumes (in my case).

|that fixes it:
|
| https://github.com/openssh/openssh-portable/pull/239

That is great! I had not looked at github. (That pull i could
not have found by then?)

|But it's failing checks on 4 Ubuntu kitchensink/sk
|versions.
|
|This page shows the error message:
|
| https://github.com/openssh/openssh-portable/actions/runs/704178803
|
| No files were found with the provided path:
| regress/*.log regress/valgrind-out/. No artifacts
| will be uploaded.

I am not at github so cannot see the log, but since configure
failed also locally, a "autoreconf" seems to fix it. After that:

make[1]: Leaving directory '/tmp/x/openssh.tar_bomb_git/regress'
unit tests passed
echo all tests passed
all tests passed

(8.5p1 plus your patch.)
It would be nice if that patch made it in.

Thanks, and Ciao from Germany,

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Dear all,

see

https://bugzilla.mindrot.org/show_bug.cgi?id=1902

for one of the first reports and also a reason why it is currently not accepted.

Best,
Bert

On Thu, Apr 1, 2021 at 12:48 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> Hello!
>
> raf wrote in
> <20210331075157.sgfbkvofdx6dgiyi@raf.org>:
> |On Wed, Mar 31, 2021 at 12:33:43AM +0200, Steffen Nurpmeso <steffen@sdao\
> |den.eu> wrote:
> |> I just stumbled over the fact that the ControlMaster process does
> |> not do "cd /" but remains where the ssh client was invoked. Is
> |> this intentional, or should i open a bug report on that?
> |>
> |> [snip]
> ...
> |I reported this too a little while ago and there was no
> |interest. But it is a pain when your cwd is a USB stick
> |that you want to umount. I've created a pull request
>
> Yeah, and encrypted volumes (in my case).
>
> |that fixes it:
> |
> | https://github.com/openssh/openssh-portable/pull/239
>
> That is great! I had not looked at github. (That pull i could
> not have found by then?)
>
> |But it's failing checks on 4 Ubuntu kitchensink/sk
> |versions.
> |
> |This page shows the error message:
> |
> | https://github.com/openssh/openssh-portable/actions/runs/704178803
> |
> | No files were found with the provided path:
> | regress/*.log regress/valgrind-out/. No artifacts
> | will be uploaded.
>
> I am not at github so cannot see the log, but since configure
> failed also locally, a "autoreconf" seems to fix it. After that:
>
> make[1]: Leaving directory '/tmp/x/openssh.tar_bomb_git/regress'
> unit tests passed
> echo all tests passed
> all tests passed
>
> (8.5p1 plus your patch.)
> It would be nice if that patch made it in.
>
> Thanks, and Ciao from Germany,
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, 8 Apr 2021, Bert Wesarg wrote:

> see
> https://bugzilla.mindrot.org/show_bug.cgi?id=1902
> for one of the first reports and also a reason why it is currently not accepted.

This seems really wrong. #1902 refers to #1988 as reason for not
chdir’ing to / but #1988 is about (1, 0) vs. (1, 1) whereas #1902
is about (0, 1) vs. (1, 1) so perhaps changing the daemon call to
(0, 0) will fix both?

bye,
//mirabilos, not (yet) having looked at that code, just wondering
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

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

Bert Wesarg wrote in
<CAKPyHN0Y9QzX4wMW7fod0Ws80Nq6VJXQFgxutAdSRMN03ZGaeQ@mail.gmail.com>:
|Dear all,
|
|see
|
| https://bugzilla.mindrot.org/show_bug.cgi?id=1902
|
|for one of the first reports and also a reason why it is currently \
|not accepted.

Ah! Sorry, i somehow missed this when searching for ControlMaster
(iirc). I do not quite get the reasoning, i think i will instead
just stop using ControlMaster, as for the first hop this now all
is a VPN anyway.

Thanks, and Ciao! from Germany,

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, Apr 08, 2021 at 12:16:42PM +0200, Bert Wesarg <bert.wesarg@googlemail.com> wrote:

> Dear all,
>
> see
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=1902
>
> for one of the first reports and also a reason why it is currently not accepted.
>
> Best,
> Bert

I must be missing something. I can't see where on that
page a reason is given, but I'll take your word for it
that there is one. :-) If it has something to do with
the comment about relative paths for known hosts files,
I don't see that as a problem. By default, the known
hosts file has a non-relative value, i.e.
~/.ssh/known_hosts. So, if that's the reason, it seems
to be a fairly weak one. In the probably rare case that
someone does manually override the default known hosts
file path, it could be documented in the manpage that
it should be set to an absolute path so as not to cause
problems with ControlMaster. That would be better than
leaving the ControlMaster problem in place for everyone
that uses ControlMaster.

cheers,
raf

> On Thu, Apr 1, 2021 at 12:48 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> >
> > Hello!
> >
> > raf wrote in
> > <20210331075157.sgfbkvofdx6dgiyi@raf.org>:
> > |On Wed, Mar 31, 2021 at 12:33:43AM +0200, Steffen Nurpmeso <steffen@sdao\
> > |den.eu> wrote:
> > |> I just stumbled over the fact that the ControlMaster process does
> > |> not do "cd /" but remains where the ssh client was invoked. Is
> > |> this intentional, or should i open a bug report on that?
> > |>
> > |> [snip]
> > ...
> > |I reported this too a little while ago and there was no
> > |interest. But it is a pain when your cwd is a USB stick
> > |that you want to umount. I've created a pull request
> >
> > Yeah, and encrypted volumes (in my case).
> >
> > |that fixes it:
> > |
> > | https://github.com/openssh/openssh-portable/pull/239
> >
> > That is great! I had not looked at github. (That pull i could
> > not have found by then?)
> >
> > |But it's failing checks on 4 Ubuntu kitchensink/sk
> > |versions.
> > |
> > |This page shows the error message:
> > |
> > | https://github.com/openssh/openssh-portable/actions/runs/704178803
> > |
> > | No files were found with the provided path:
> > | regress/*.log regress/valgrind-out/. No artifacts
> > | will be uploaded.
> >
> > I am not at github so cannot see the log, but since configure
> > failed also locally, a "autoreconf" seems to fix it. After that:
> >
> > make[1]: Leaving directory '/tmp/x/openssh.tar_bomb_git/regress'
> > unit tests passed
> > echo all tests passed
> > all tests passed
> >
> > (8.5p1 plus your patch.)
> > It would be nice if that patch made it in.
> >
> > Thanks, and Ciao from Germany,
> >
> > --steffen
> > |
> > |Der Kragenbaer, The moon bear,
> > |der holt sich munter he cheerfully and one by one
> > |einen nach dem anderen runter wa.ks himself off
> > |(By Robert Gernhardt)
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, Apr 08, 2021 at 02:48:59PM +0200, Thorsten Glaser <t.glaser@tarent.de> wrote:

> On Thu, 8 Apr 2021, Bert Wesarg wrote:
>
> > see
> > https://bugzilla.mindrot.org/show_bug.cgi?id=1902
> > for one of the first reports and also a reason why it is currently not accepted.
>
> This seems really wrong. #1902 refers to #1988 as reason for not
> chdir’ing to / but #1988 is about (1, 0) vs. (1, 1) whereas #1902
> is about (0, 1) vs. (1, 1) so perhaps changing the daemon call to
> (0, 0) will fix both?
>
> bye,
> //mirabilos, not (yet) having looked at that code, just wondering

Ah, #1988 is the reason. I would think that if that problem
was that stderr is left open, the solution is to close stderr
(when not debugging), rather than to not chdir /.

cheers,
raf

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

On Fri, Apr 09, 2021 at 01:41:47PM +1000, raf <ssh@raf.org> wrote:

> On Thu, Apr 08, 2021 at 02:48:59PM +0200, Thorsten Glaser <t.glaser@tarent.de> wrote:
>
> > On Thu, 8 Apr 2021, Bert Wesarg wrote:
> >
> > > see
> > > https://bugzilla.mindrot.org/show_bug.cgi?id=1902
> > > for one of the first reports and also a reason why it is currently not accepted.
> >
> > This seems really wrong. #1902 refers to #1988 as reason for not
> > chdir’ing to / but #1988 is about (1, 0) vs. (1, 1) whereas #1902
> > is about (0, 1) vs. (1, 1) so perhaps changing the daemon call to
> > (0, 0) will fix both?
> >
> > bye,
> > //mirabilos, not (yet) having looked at that code, just wondering
>
> Ah, #1988 is the reason. I would think that if that problem
> was that stderr is left open, the solution is to close stderr
> (when not debugging), rather than to not chdir /.
>
> cheers,
> raf

The current code has daemon(1, 1) in control_persist_detach().
The stderr problem is handled separately. So I think it needs
to be changed to daemon(0, 1). I've created a new pull request
to do it that way:

https://github.com/openssh/openssh-portable/pull/243

cheers,
raf

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

Just like stdout, stderr is essential for programs that the user runs on
the remote machine.  Please don't close it unless and until the user
does (e.g. ssh remote 'exec command 2>&-')



-------- Forwarded Message --------
Subject: Re: ControlMaster cwd is not /
Date: Fri, 9 Apr 2021 13:41:47 +1000
From: raf <ssh@raf.org>
To: Thorsten Glaser <t.glaser@tarent.de>
CC: Bert Wesarg <bert.wesarg@googlemail.com>, openssh-unix-dev@mindrot.org



On Thu, Apr 08, 2021 at 02:48:59PM +0200, Thorsten Glaser
<t.glaser@tarent.de> wrote:

> On Thu, 8 Apr 2021, Bert Wesarg wrote:
>
> > see
> > https://bugzilla.mindrot.org/show_bug.cgi?id=1902
> > for one of the first reports and also a reason why it is currently
> not accepted.
>
> This seems really wrong. #1902 refers to #1988 as reason for not
> chdir’ing to / but #1988 is about (1, 0) vs. (1, 1) whereas #1902
> is about (0, 1) vs. (1, 1) so perhaps changing the daemon call to
> (0, 0) will fix both?
>
> bye,
> //mirabilos, not (yet) having looked at that code, just wondering

Ah, #1988 is the reason. I would think that if that problem
was that stderr is left open, the solution is to close stderr
(when not debugging), rather than to not chdir /.

cheers,
raf

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

On Fri, Apr 09, 2021 at 02:31:14PM +0930, David Newall <openssh@davidnewall.com> wrote:

> Just like stdout, stderr is essential for programs that the user runs on the
> remote machine.? Please don't close it unless and until the user does (e.g.
> ssh remote 'exec command 2>&-')

This is referring to the stderr of a separate process
to the main ssh process. When ControlMaster is in use,
and ssh is used to make a connection to a remote host,
a separate daemon/background process is started that
listens for subsequent attempts to connect to the same
remote host with ssh. It listens to a control socket
for a certain time period. This enables subsequent
connections to the same remote host to start up much
more quickly by re-using the setup work done by the
first connection rather than performing the same setup
work for every connection.

It's the stderr of that second daemon/background
process that gets closed, not the stderr of the primary
ssh process that makes the initial connection to the
remote host in question. It's only the primary ssh
process that is communicating with the remote host
(from the user's point of view), and therefore needs
its stdout and stderr to remain open, and they will
remain open even if the (duplicate) stderr of the
second daemon/background process is closed.

The closing of stderr in the daemon/background process
that listens to the control socket is already
happening, and has been happening for years. This
discussion does not affect that. It is only about
making the secondary daemon/background process also
change its current working directory to the root
directory (/), rather than leaving it as whatever
directory the user was in when starting the initial ssh
process, so as to prevent hampering a subsequent umount
of the file system that contains that current working
directory.

This change means that if the user's current working
directory was in a temporary file system such as a
removable USB stick, or an encrypted file system, and
the user subsequently wants to umount that
corresponding file system, the operating system won't
allow it if there are any processes that are still
using the file system.

When the daemon/background process's current working
directory is in the file system that the user wants to
umount, they won't be able to do so until they have
identified the daemon/background process and terminated
it manually. If that process had changed its working
directory to the root directory, then the umount would
just work.

It's normal practice for daemon processes to change
their current working directory to the root directory
for this reason, but ssh's secondary daemon/background
process that listens to the control socket doesn't do
this. I don't think that there was any particularly
good reason for this. It was probably just to minimise
the change to the ssh code when the call to daemon()
was introduced. Before the introduction of the call to
daemon(), there was no chdir(), so when daemon() was
added, it was called in a way that also didn't do a
chdir() (even though that isn't normal practice for
daemon processes). But a chdir() at that point would be
an improvement.

cheers,
raf

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