bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when startin


From: Ulrich Mueller
Subject: bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when starting daemon on-demand
Date: Wed, 08 Dec 2021 22:56:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

>>>>> On Wed, 08 Dec 2021, Stefan Kangas wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> Date: Wed, 8 Dec 2021 11:06:12 -0800
>>> Cc: 51327@debbugs.gnu.org
>>> From: Paul Eggert <eggert@cs.ucla.edu>
>>> 
>>> On 12/7/21 22:57, Jim Porter wrote:
>>> > Doing that by default opens a loophole for all emacsclient users, but
>>> > what about a command-line flag like `emacsclient
>>> > --allow-tmpdir-loophole' and/or an environment variable like
>>> > `EMACS_ALLOW_TMPDIR_LOOPHOLE=1 emacsclient' (with a better name, of
>>> > course)? Then, the default behavior would be free of loopholes[2], but
>>> > Ulrich's case could be achieved by passing that flag when calling
>>> > emacsclient. It might even be possible for Gentoo to enable that for the
>>> > user in the appropriate cases...
>>> 
>>> Yes, I think something like this would be OK. The command-line flag
>>> would be easier to audit.
>>> 
>>> Not sure whether a last-minute change like this should go into Emacs 28,
>>> though, even though it's security-relevant. Eli would be a better judge
>>> of that.
>> 
>> If it's a new command-line argument, and if the participants in this
>> discussion can live with it as the solution for this problem, I'm okay
>> with having it on emacs-28.

That's not an acceptable solution, because it will break the existing
workflow of users. Furthermore, it will make users jump through hoops to
achieve functionality which was the default in previous versions.

So, can we please think about a better solution, and not knee-jerk
something half-baked into Emacs 28, like checking for yet another
environment variable?

Even reverting to the Emacs 27 behaviour would be better than what has
been suggested above: In Emacs 27, you can set EMACS_SOCKET_NAME to make
things work. There's no advantage in introducing yet another variable,
which would only complicate things.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]