unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: 24478@debbugs.gnu.org, Ted Zlatanov <tzz@lifelogs.com>
Subject: bug#24478: 25.1; Regression in 25.1: .tramp_history files are littered in non-$HOME working directories
Date: Tue, 11 Oct 2016 15:54:36 +0200	[thread overview]
Message-ID: <87y41vm1nn.fsf@gmx.de> (raw)
In-Reply-To: <CACBZZX7Gb9cSbNCPdooMpupNLKhHAPyrR5ohcqAVt=wE8kUwJg@mail.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Mon, 10 Oct 2016 13:14:57 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Hi Ævar,

> I'm the reporter, so I obviously have a dog in this fight, but I don't
> think that makes sense. This whole facility introduced in the emacs-25
> series still seems really broken since its introduction, and the
> various regressions reported have just resulted in other regressions
> taking their place, the latest one being discussed in this ticket.

I'm also unhappy about this story. I really would like to use a proper
and robust default value for this. But there isn't one so far.

>  * In emacs-24 there was no way to have a Tramp history file, we'd
> just specify a HISTFILE=/dev/null environment variable.

This was introduced back in 2014. Before this change, HISFILE was unset
somewhere else in the initialization hand-shake, but at a later
point. It didn't work properly then.

>  * 9be1538 added an option to change that, so you could have a history
> file as a file, defaulting to /dev/null, but they way it was
> implemented caused it to unlink /dev/null, as reported in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19731

Bug#19371 has reported, that there is a bash bug
<https://bbs.archlinux.org/viewtopic.php?pid=1397412#p1397412> which has
this effect. It is no Tramp error, and I would regard this setting still
be the best one if possible. But due to this bash bug, this setting
would damage the remote system. So we cannot use "/dev/null" as default,
even if the bash bug has been fixed. There will still be system in the
wild with this bug.

>  * So Michael patched it to make 'unset an option, which was
> implemented in 6f8372d, as far as I can tell at this point the
> facility worked the way it did in emacs-24 again. I.e. no history by
> default, but no regression with unlinking /dev/null
>
>  * 'unset was made the default by Michael in 954ca0f, but just a few
> hours later this was set to t instead in c10828b, which does the same
> thing as 'unset according to the commit message. I.e. just an internal
> refactoring. This was followed-up by 24fa4ff to refactor it some more.

Yes.

> * It was then changed from t to ".tramp_history" in 1e04ea9. The
> commit message says to fix
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20446 but I don't see
> how it could eat the bash history if it's set to not have any history
> file by default.

Glenn did report, that in his use case unsetting HISTFILE has changed
his ~/.bash_history to a zero size. Not acceptable, and again a special
behaviour of bash :-(

So the only solution I could thing about is setting this variable to a
Tramp specific value.

> * Now because it's ".tramp_history" and not "~/.tramp_history" it gets
> created in random non-~ directories you open with tramp, but more
> importantly, and I didn't realize this in my initial report, the shell
> history *might be shared between multiple users*, which seems like a
> bad security issue.

"~/.tramp_history" would be the obvious choice, but "~/" is not
guaranteed to exist. An example is hydra, were the tests failed with
this setting.

> It seems to me that the best solution to this whole problem is to set
> it to "t" again which would return to the non-history days of
> emacs-24, since apparently using ~ can't be counted on.

How do you want explain it to bash users like Glenn? Their history file
will get lost, again.

> In addition, depending on the bug with history potentially being
> shared between users now that it's being dumped in random potentially
> shared FS directories they open with tramp, changing this to
> ".tramp_history" might have caused a security issue worth of a CVE,
> but I haven't investigated that, but we *certainly* went from no
> history by default in emacs-24 to history littered in potentially
> world readable directories in emacs-25.

I still don't understand why the ".tramp_history" file is spread over
the file system. This setting is apllied immediately after connecting to
the remote host. I would assume that one lands in the home directory
there; ".tramp_history" should be expanded relatively to that directory.

Could you show hot it happens to you that it is expanded to another
place? Pls run Tramp from scratch, after increasing the debug level by

(setq tramp-verbose 6)

There will be a Tramp debug buffer, which might tell us what happens.

Best regards, Michael.





  reply	other threads:[~2016-10-11 13:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 10:21 bug#24478: 25.1; Regression in 25.1: .tramp_history files are littered in non-$HOME working directories Ævar Arnfjörð Bjarmason
2016-09-22 18:02 ` Michael Albinus
2016-10-10 10:38   ` Eli Zaretskii
2016-10-10 11:14     ` Ævar Arnfjörð Bjarmason
2016-10-11 13:54       ` Michael Albinus [this message]
2016-10-11 14:34         ` Ævar Arnfjörð Bjarmason
2016-10-11 14:44           ` Michael Albinus
2016-10-11 14:47             ` Ævar Arnfjörð Bjarmason
2016-10-12 14:05               ` Michael Albinus
2016-10-13 14:51                 ` Michael Albinus
2016-10-13 15:18                   ` Ævar Arnfjörð Bjarmason
2016-10-13 16:30                     ` Michael Albinus
2016-10-15 10:38                       ` Michael Albinus
2016-10-22 16:55                         ` Michael Albinus
2016-10-23 23:29                           ` Glenn Morris
2016-10-24  7:09                             ` Michael Albinus
2016-10-24 13:10                       ` Michael Albinus
2016-10-24 13:54                         ` Ævar Arnfjörð Bjarmason
2016-10-24 14:32                           ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y41vm1nn.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=24478@debbugs.gnu.org \
    --cc=avarab@gmail.com \
    --cc=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).