GNU bug report logs - #38265
26.3; lock file is too easy to steal

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 38265 in the body.
You can then email your comments to 38265 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: Allen Li <darkfeline <at> felesatra.moe>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; lock file is too easy to steal
Date: Tue, 19 Nov 2019 00:35:34 -0800

The default ask-user-about-lock is too easy to miss.

For example, if one were typing "asparagus", they would likely steal the
lock without even realizing that it happened (the "a" triggers the
prompt on buffer modification and the "s" steals the lock).

It would be nice to have the prompt be harder to hit accidentally, such
as making all of the keys uppercase or having to type them out like
yes/no (but the latter might be too heavyweight).  Or the prompt should
have a short timeout before allowing the user to respond (like how
yes-or-no-p does when you provide an invalid response).

In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description:	Arch Linux

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

From: Juri Linkov <juri <at> linkov.net>
To: Allen Li <darkfeline <at> felesatra.moe>
Cc: 38265 <at> debbugs.gnu.org
Subject: Re: bug#38265: 26.3; lock file is too easy to steal
Date: Thu, 21 Nov 2019 00:28:09 +0200

> The default ask-user-about-lock is too easy to miss.
>
> For example, if one were typing "asparagus", they would likely steal the
> lock without even realizing that it happened (the "a" triggers the
> prompt on buffer modification and the "s" steals the lock).
>
> It would be nice to have the prompt be harder to hit accidentally, such
> as making all of the keys uppercase or having to type them out like
> yes/no (but the latter might be too heavyweight).  Or the prompt should
> have a short timeout before allowing the user to respond (like how
> yes-or-no-p does when you provide an invalid response).

On the request in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00517.html
recently ‘(discard-input)’ was removed from ‘read-char-from-minibuffer’.
Should it be put back?

ask-user-about-supersession-threat uses read-char-from-minibuffer, so if
it contained ‘(discard-input)’ it could benefit from discarding such
inadvertent input as "s".

But what about the case of keyboard macros like in the link above?
What if the user recorded a keyboard macro to input that "s" intentionally?

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

From: Juri Linkov <juri <at> linkov.net>
To: Allen Li <darkfeline <at> felesatra.moe>
Cc: 38265 <at> debbugs.gnu.org
Subject: Re: bug#38265: 26.3; lock file is too easy to steal
Date: Mon, 16 Dec 2019 02:04:39 +0200

>>> The default ask-user-about-lock is too easy to miss.
>>>
>>> For example, if one were typing "asparagus", they would likely steal the
>>> lock without even realizing that it happened (the "a" triggers the
>>> prompt on buffer modification and the "s" steals the lock).
>>>
>>> It would be nice to have the prompt be harder to hit accidentally, such
>>> as making all of the keys uppercase or having to type them out like
>>> yes/no (but the latter might be too heavyweight).  Or the prompt should
>>> have a short timeout before allowing the user to respond (like how
>>> yes-or-no-p does when you provide an invalid response).
>>
>> On the request in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00517.html
>> recently ‘(discard-input)’ was removed from ‘read-char-from-minibuffer’.
>> Should it be put back?
>>
>> ask-user-about-supersession-threat uses read-char-from-minibuffer, so if
>> it contained ‘(discard-input)’ it could benefit from discarding such
>> inadvertent input as "s".
>>
>> But what about the case of keyboard macros like in the link above?
>> What if the user recorded a keyboard macro to input that "s" intentionally?
>
> We could check executing-kbd-macro and disable "interactive safety
> features".  That seems like a valid use case of executing-kbd-macro.

Yes, executing-kbd-macro could help.  Have you tried it?

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

From: Allen Li <darkfeline <at> felesatra.moe>
To: Juri Linkov <juri <at> linkov.net>
Cc: 38265 <at> debbugs.gnu.org
Subject: Re: bug#38265: 26.3; lock file is too easy to steal
Date: Thu, 26 Dec 2019 11:22:14 -0800

Juri Linkov <juri <at> linkov.net> writes:

>>>> The default ask-user-about-lock is too easy to miss.
>>>>
>>>> For example, if one were typing "asparagus", they would likely steal the
>>>> lock without even realizing that it happened (the "a" triggers the
>>>> prompt on buffer modification and the "s" steals the lock).
>>>>
>>>> It would be nice to have the prompt be harder to hit accidentally, such
>>>> as making all of the keys uppercase or having to type them out like
>>>> yes/no (but the latter might be too heavyweight).  Or the prompt should
>>>> have a short timeout before allowing the user to respond (like how
>>>> yes-or-no-p does when you provide an invalid response).
>>>
>>> On the request in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00517.html
>>> recently ‘(discard-input)’ was removed from ‘read-char-from-minibuffer’.
>>> Should it be put back?
>>>
>>> ask-user-about-supersession-threat uses read-char-from-minibuffer, so if
>>> it contained ‘(discard-input)’ it could benefit from discarding such
>>> inadvertent input as "s".
>>>
>>> But what about the case of keyboard macros like in the link above?
>>> What if the user recorded a keyboard macro to input that "s" intentionally?
>>
>> We could check executing-kbd-macro and disable "interactive safety
>> features".  That seems like a valid use case of executing-kbd-macro.
>
> Yes, executing-kbd-macro could help.  Have you tried it?

Tried how?  I have not tried to patch the (discard-input) change to
check executing-kbd-macro, nor tried whether the (discard-input) change
addresses the concern in the original bug.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Allen Li <darkfeline <at> felesatra.moe>
Cc: 38265 <at> debbugs.gnu.org
Subject: Re: bug#38265: 26.3; lock file is too easy to steal
Date: Wed, 11 Aug 2021 14:40:40 +0200

Allen Li <darkfeline <at> felesatra.moe> writes:

> The default ask-user-about-lock is too easy to miss.
>
> For example, if one were typing "asparagus", they would likely steal the
> lock without even realizing that it happened (the "a" triggers the
> prompt on buffer modification and the "s" steals the lock).
>
> It would be nice to have the prompt be harder to hit accidentally, such
> as making all of the keys uppercase or having to type them out like
> yes/no (but the latter might be too heavyweight).  Or the prompt should
> have a short timeout before allowing the user to respond (like how
> yes-or-no-p does when you provide an invalid response).

I think making the lock prompt more extensive would be pretty
annoying -- we only use yes-or-no-p (and related) when doing something
destructive or dangerous, and stealing the lock isn't that dangerous.

So I think the current level of prompting is fine, and if you want more
prompting, then it should be easy enough to redefine/advice
ask-user-about-lock to be harder to get past, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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