* bug#30946: 26.0.90; TRAMP cannot access some files when using hops @ 2018-03-26 8:42 Nicolas Petton 2018-03-29 14:11 ` Michael Albinus [not found] ` <6e181a50-452c-0e8b-ae5a-0746f64a6dfb@orcon.net.nz> 0 siblings, 2 replies; 9+ messages in thread From: Nicolas Petton @ 2018-03-26 8:42 UTC (permalink / raw) To: 30946 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-03-26 8:42 bug#30946: 26.0.90; TRAMP cannot access some files when using hops Nicolas Petton @ 2018-03-29 14:11 ` Michael Albinus 2018-04-03 12:02 ` Nicolas Petton [not found] ` <6e181a50-452c-0e8b-ae5a-0746f64a6dfb@orcon.net.nz> 1 sibling, 1 reply; 9+ messages in thread From: Michael Albinus @ 2018-03-29 14:11 UTC (permalink / raw) To: Nicolas Petton; +Cc: 30946 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-03-29 14:11 ` Michael Albinus @ 2018-04-03 12:02 ` Nicolas Petton 0 siblings, 0 replies; 9+ messages in thread From: Nicolas Petton @ 2018-04-03 12:02 UTC (permalink / raw) To: Michael Albinus; +Cc: 30946-done, 30946 [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <6e181a50-452c-0e8b-ae5a-0746f64a6dfb@orcon.net.nz>]
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops [not found] ` <6e181a50-452c-0e8b-ae5a-0746f64a6dfb@orcon.net.nz> @ 2018-12-30 22:01 ` Phil Sainty 2018-12-31 11:20 ` Michael Albinus 0 siblings, 1 reply; 9+ messages in thread From: Phil Sainty @ 2018-12-30 22:01 UTC (permalink / raw) To: 30946 (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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-12-30 22:01 ` Phil Sainty @ 2018-12-31 11:20 ` Michael Albinus 2018-12-31 12:40 ` Phil Sainty 0 siblings, 1 reply; 9+ messages in thread From: Michael Albinus @ 2018-12-31 11:20 UTC (permalink / raw) To: Phil Sainty; +Cc: 30946 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-12-31 11:20 ` Michael Albinus @ 2018-12-31 12:40 ` Phil Sainty 2018-12-31 14:13 ` Michael Albinus 0 siblings, 1 reply; 9+ messages in thread From: Phil Sainty @ 2018-12-31 12:40 UTC (permalink / raw) To: Michael Albinus; +Cc: 30946 > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-12-31 12:40 ` Phil Sainty @ 2018-12-31 14:13 ` Michael Albinus 2018-12-31 21:48 ` Phil Sainty 0 siblings, 1 reply; 9+ messages in thread From: Michael Albinus @ 2018-12-31 14:13 UTC (permalink / raw) To: Phil Sainty; +Cc: 30946 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-12-31 14:13 ` Michael Albinus @ 2018-12-31 21:48 ` Phil Sainty 2019-01-01 11:54 ` Michael Albinus 0 siblings, 1 reply; 9+ messages in thread From: Phil Sainty @ 2018-12-31 21:48 UTC (permalink / raw) To: Michael Albinus; +Cc: 30946-done 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#30946: 26.0.90; TRAMP cannot access some files when using hops 2018-12-31 21:48 ` Phil Sainty @ 2019-01-01 11:54 ` Michael Albinus 0 siblings, 0 replies; 9+ messages in thread From: Michael Albinus @ 2019-01-01 11:54 UTC (permalink / raw) To: Phil Sainty; +Cc: 30946-done 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-01 11:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-26 8:42 bug#30946: 26.0.90; TRAMP cannot access some files when using hops Nicolas Petton 2018-03-29 14:11 ` Michael Albinus 2018-04-03 12:02 ` Nicolas Petton [not found] ` <6e181a50-452c-0e8b-ae5a-0746f64a6dfb@orcon.net.nz> 2018-12-30 22:01 ` Phil Sainty 2018-12-31 11:20 ` Michael Albinus 2018-12-31 12:40 ` Phil Sainty 2018-12-31 14:13 ` Michael Albinus 2018-12-31 21:48 ` Phil Sainty 2019-01-01 11:54 ` Michael Albinus
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.