GNU bug report logs - #30946
26.0.90; TRAMP cannot access some files when using hops

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30946 in the body.
You can then email your comments to 30946 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90; TRAMP cannot access some files when using hops
Date: Mon, 26 Mar 2018 10:42:43 +0200

As discussed on the emacs-devel mailing list, when using tramp with
multiple hops like the following:

  C-x C-f /ssh:me <at> example.com|sudo:localhost:/etc/deluser.conf

Tramp opens an empty buffer, without showing any error message.

I understand now that the second hop should be "sudo:example.com:", but
it felt intuitive to use localhost, and for most files on the remote
host it actually worked.

Message #8 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Thu, 29 Mar 2018 16:11:02 +0200

Nicolas Petton <nicolas <at> petton.fr> writes:

Hi Nicolas,

> As discussed on the emacs-devel mailing list, when using tramp with
> multiple hops like the following:
>
>   C-x C-f /ssh:me <at> example.com|sudo:localhost:/etc/deluser.conf
>
> Tramp opens an empty buffer, without showing any error message.
>
> I understand now that the second hop should be "sudo:example.com:", but
> it felt intuitive to use localhost, and for most files on the remote
> host it actually worked.

I have added an additional check in Tramp for host name matches in such
cases. This checks also the single hop case "/sudo:example.com:", which
shall fail when "example.com" is not your local host name.

There's a new test case for this, tramp-test03-file-name-host-rules. I
have the feeling that this test needs too much time; maybe I'll move it
to the expensive tests.

Could you pls check, whether Tramp behaves now as expected?

Best regards, Michael.

Message #11 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 30946-done <at> debbugs.gnu.org, 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Tue, 03 Apr 2018 14:02:05 +0200

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Michael,

> I have added an additional check in Tramp for host name matches in such
> cases. This checks also the single hop case "/sudo:example.com:", which
> shall fail when "example.com" is not your local host name.
>
> There's a new test case for this, tramp-test03-file-name-host-rules. I
> have the feeling that this test needs too much time; maybe I'll move it
> to the expensive tests.
>
> Could you pls check, whether Tramp behaves now as expected?

It works fine (and thank you for documenting it as well).

Cheers,
Nico

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Mon, 31 Dec 2018 11:01:46 +1300

(resending this to just the bug address, after unarchiving)

On 26/03/18 9:42 PM, Nicolas Petton wrote:
> As discussed on the emacs-devel mailing list, when using tramp with
> multiple hops like the following:
>
>   C-x C-f /ssh:me <at> example.com|sudo:localhost:/etc/deluser.conf
>
> Tramp opens an empty buffer, without showing any error message.
>
> I understand now that the second hop should be "sudo:example.com:",
> but it felt intuitive to use localhost, and for most files on the
> remote host it actually worked.

I'd suspect that https://stackoverflow.com/a/16408592/324105 explains
why it 'worked':

> The trap here is that sudo:: does actually appear to work -- however
> when you do that the HOST for the dynamic proxy entry will be the
> hostname you originated from rather than the host you connected
> to. This will not only look confusing (as the wrong host will be
> displayed in the file paths), but it will also mean that any
> subsequent attempt to use sudo:: on your localhost will instead be
> proxied to the remote server!

i.e. /ssh:me <at> example.com|sudo:localhost was previously creating a proxy
that said that when you request files as root <at> localhost (for *any*
tramp method!) it should proxy via "/ssh:me <at> example.com:".  The sudo
method didn't actually need or care about the specified host, so that
"worked" -- but the proxy you'd created was then a problem waiting to
bite you.


Ooohh.

Michael, that actually still remains a problem in the new version.

Despite the error message, the unintended proxy is still created,
and hence can still break things.

i.e. I try to visit:

/ssh:me <at> example.com|sudo:localhost

I get the new error message:

Host name ‘localhost’ does not match ‘^example.com$’

but I *also* get a new proxy entry:

("localhost" "root" "/ssh:me <at> example.com:")

So when I then visit:

/sudo:localhost:

I get the error message:

Host name ‘localhost’ does not match ‘^example.com$’

etc, etc...


Conversely, it seems that the "::" case has been attended to so that
it now transparently DWIM ?

i.e. When I try /ssh:me <at> example.com|sudo:: I get a proxy entry of:
("example.com" "root" "/ssh:me <at> example.com:")

whereas in earlier versions of Emacs I get the undesirable:
("<FOO>" "root" "/ssh:me <at> example.com:")
Where <FOO> is my local hostname.

That's excellent, and possibly also deserves a note in the NEWS?

Currently it reads:

*** For some connection methods, like "su" or "sudo", the host name in
ad-hoc multi-hop file names must match the previous hop.

We could perhaps append:

If the hostname is left empty (e.g. "sudo::") then the host from the
previous hop is used automatically.


cheers,
-Phil


p.s. I find the new error slightly confusing to dismiss.  It's not
entirely obvious how to get back to the prompt.  Not a big problem,
as ideally people don't run into it at all, but I just thought I'd
mention it.

The error sticks around persistently until I type C-g, at which point
I get a new error "Tramp: Opening connection for root <at> localhost using
sudo...failed".  That error also sticks around for a couple of seconds,
which is long enough to make one suspect that it also needs to be
dismissed with C-g -- which will actually exit the minibuffer entirely,
meaning you can't simply edit the incorrect path to fix the problem,
but must start over.

(So the correct sequence is C-g and then either wait a couple of
seconds, or just start typing blindly.)

It would be nice if that was a bit smoother -- but again, I don't
think this is a significant issue in reality, so I wouldn't worry
about it unless you think it's easy to deal with.

Message #30 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Mon, 31 Dec 2018 12:20:04 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

Hi Phil,

> i.e. /ssh:me <at> example.com|sudo:localhost was previously creating a proxy
> that said that when you request files as root <at> localhost (for *any*
> tramp method!) it should proxy via "/ssh:me <at> example.com:".  The sudo
> method didn't actually need or care about the specified host, so that
> "worked" -- but the proxy you'd created was then a problem waiting to
> bite you.
>
> Ooohh.
>
> Michael, that actually still remains a problem in the new version.
>
> Despite the error message, the unintended proxy is still created,
> and hence can still break things.
>
> i.e. I try to visit:
>
> /ssh:me <at> example.com|sudo:localhost
>
> I get the new error message:
>
> Host name ‘localhost’ does not match ‘^example.com$’
>
> but I *also* get a new proxy entry:
>
> ("localhost" "root" "/ssh:me <at> example.com:")
>
> So when I then visit:
>
> /sudo:localhost:
>
> I get the error message:
>
> Host name ‘localhost’ does not match ‘^example.com$’
>
> etc, etc...

Ad-hoc proxy definitions are removed by "M-x
tramp-cleanup-all-connections". I've added a respective hint to the manual.

> Conversely, it seems that the "::" case has been attended to so that
> it now transparently DWIM ?
>
> i.e. When I try /ssh:me <at> example.com|sudo:: I get a proxy entry of:
> ("example.com" "root" "/ssh:me <at> example.com:")

Yes. This was already documented in the Tramp manual.

> whereas in earlier versions of Emacs I get the undesirable:
> ("<FOO>" "root" "/ssh:me <at> example.com:")
> Where <FOO> is my local hostname.
>
> That's excellent, and possibly also deserves a note in the NEWS?

The previous behaviour was a bug. I've corrected it. Bugs don't need to
be mentioned in etc/NEWS. I've extended the NEWS entry to describe the
new default host name behavior.

> cheers,
> -Phil
>
> p.s. I find the new error slightly confusing to dismiss.  It's not
> entirely obvious how to get back to the prompt.  Not a big problem,
> as ideally people don't run into it at all, but I just thought I'd
> mention it.
>
> The error sticks around persistently until I type C-g, at which point
> I get a new error "Tramp: Opening connection for root <at> localhost using
> sudo...failed".  That error also sticks around for a couple of seconds,
> which is long enough to make one suspect that it also needs to be
> dismissed with C-g -- which will actually exit the minibuffer entirely,
> meaning you can't simply edit the incorrect path to fix the problem,
> but must start over.
>
> (So the correct sequence is C-g and then either wait a couple of
> seconds, or just start typing blindly.)
>
> It would be nice if that was a bit smoother -- but again, I don't
> think this is a significant issue in reality, so I wouldn't worry
> about it unless you think it's easy to deal with.

See above. Some "C-g" in a raw (let's say, two or three times) plus
"M-x tramp-cleanup-all-connections" shall be sufficient.

Best regards, Michael.

Message #33 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Tue, 1 Jan 2019 01:40:54 +1300

> Ad-hoc proxy definitions are removed by
> "M-x tramp-cleanup-all-connections".
> I've added a respective hint to the manual.

Right; but given that there is now some form of error detection in the
case when a clearly-incorrect hostname is given for the sudo/su methods,
would it not be very sensible to also ensure that a proxy matching the
incorrect hostname is not added?

As it is, the error is 'caught' but the unwanted behaviour silently
happens anyway, which seems bad to me; especially when any subsequent
use of that proxy is likely to be pretty confounding.  In the worst
case someone can end up unwittingly connecting to a different machine
than the one they intended, at which point they could inadvertently
cause themselves real problems.

Sure, it's ultimately their mistake; but when that mistake was actually
detected at the outset, it seems a shame not to deal with it then.


-Phil

Message #36 received at 30946 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 30946 <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Mon, 31 Dec 2018 15:13:15 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

Hi Phil,

>> Ad-hoc proxy definitions are removed by
>> "M-x tramp-cleanup-all-connections".
>> I've added a respective hint to the manual.
>
> Right; but given that there is now some form of error detection in the
> case when a clearly-incorrect hostname is given for the sudo/su methods,
> would it not be very sensible to also ensure that a proxy matching the
> incorrect hostname is not added?

I've pushed a fix for this to the master branch; could you pls check?

> -Phil

Best regards, Michael.

Message #39 received at 30946-done <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 30946-done <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Tue, 1 Jan 2019 10:48:29 +1300

Hi Michael,

On 1/01/19 3:13 AM, Michael Albinus wrote:
> I've pushed a fix for this to the master branch; could you pls check?

Yes, the tramp master branch works nicely!

http://git.savannah.gnu.org/cgit/tramp.git/commit/?id=1dbd930da8 does
make me wonder whether it would be good for tramp-user-error to check
whether saved-tdpa is bound, and handle the rollback itself, so the
code which sets the error doesn't need to?

I assume there are other error cases where the rollback doesn't happen
and doesn't *need* to happen; but if it's harmless to do so (which I
have no idea about), then "roll back any new proxies in the face of an
error" might well be a sane behaviour, and might possibly prevent
undesirable proxies being added in other situations (speculating).

I'm re-closing this bug in any case.  Thank you for fixing this.


-Phil

Message #42 received at 30946-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 30946-done <at> debbugs.gnu.org
Subject: Re: bug#30946: 26.0.90; TRAMP cannot access some files when using hops
Date: Tue, 01 Jan 2019 12:54:12 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

> Hi Michael,

Hi Phil,

> http://git.savannah.gnu.org/cgit/tramp.git/commit/?id=1dbd930da8 does
> make me wonder whether it would be good for tramp-user-error to check
> whether saved-tdpa is bound, and handle the rollback itself, so the
> code which sets the error doesn't need to?

`tramp-user-error' is Tramp's counterpart to `user-error'. No rollback,
or something else.

> -Phil

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.