bug#30946: 26.0.90; TRAMP cannot access some files when using hops

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Nicolas Petton]

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

  C-x C-f /ssh:me@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.

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Michael Albinus]

Nicolas Petton <nicolas@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@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.

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Michael Albinus <michael.albinus@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Phil Sainty]

(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@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@example.com|sudo:localhost was previously creating a proxy
that said that when you request files as root@localhost (for *any*
tramp method!) it should proxy via "/ssh:me@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@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@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@example.com|sudo:: I get a proxy entry of:
("example.com" "root" "/ssh:me@example.com:")

whereas in earlier versions of Emacs I get the undesirable:
("<FOO>" "root" "/ssh:me@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@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.

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Michael Albinus]

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

Hi Phil,

> i.e. /ssh:me@example.com|sudo:localhost was previously creating a proxy
> that said that when you request files as root@localhost (for *any*
> tramp method!) it should proxy via "/ssh:me@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@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@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@example.com|sudo:: I get a proxy entry of:
> ("example.com" "root" "/ssh:me@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@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@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.

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Phil Sainty]

> 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

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Michael Albinus]

Phil Sainty <psainty@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.

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Phil Sainty]

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

bug#30946: 26.0.90; TRAMP cannot access some files when using hops

[Michael Albinus]

Phil Sainty <psainty@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.