Possible race condition when using "sudo -e" or "sudoedit" #1743

rhask commented 2024年06月21日 03:16:21 +02:00

Foot Version

foot version: 1.17.2 +pgo +ime +graphemes -assertions +ucurl

TERM environment variable

foot

Compositor Version

sway version 1.9

Description of Bug and Steps to Reproduce

I have been trying to track down the source of this bug for quite some time. When using foot to run vim (latest version compiled from source) specifically via sudoedit or sudo -e where EDITOR=vim, sometimes Vim receives erroneous inputs immediately upon launching the program. Specifically, it appears to execute a 'normal mode paste' ("P") and inserts a number in the first position of the second line of the file (at the very least).

This issue does not occur every time sudoedit is used and I cannot reproduce when running via strace (which inadvertently introduces delay to Vim's startup). It only occurs with foot and not when using tmux (tested on alacritty as well).

This sequence in particular...
^[[?12l^[[?25h^[[2;1H▽^[[6n^[[2;1H ^[[3;1H^[Pzz^[\^[[0%m^[[6n^[[3;1H
... appears early in Vim's initialization, and I hasten to wonder whether it could be related/misinterpreted based on the environment.

I am not terribly familiar with how foot works, but perhaps this may assist someone in discovering why this may occur. I'm using the terminfo foot provides. I'll continue to try and uncover where this bug is coming from, but I first noticed it many months ago and I'm sure it has remained between versions of foot. Various forms of debugging haven't revealed much as there is no 'error,' but unpredictable behavior due to some confounding variable when using sudo -e.

Relevant logs, stacktraces, etc.

No response

### Foot Version foot version: 1.17.2 +pgo +ime +graphemes -assertions +ucurl ### TERM environment variable foot ### Compositor Version sway version 1.9 ### Description of Bug and Steps to Reproduce I have been trying to track down the source of this bug for quite some time. When using foot to run `vim` (latest version compiled from source) _specifically_ via `sudoedit` or `sudo -e` where `EDITOR=vim`, _**sometimes**_ Vim receives erroneous inputs immediately upon launching the program. Specifically, it appears to execute a 'normal mode paste' ("P") and inserts a number in the first position of the second line of the file (at the very least). This issue does not occur every time sudoedit is used and I cannot reproduce when running via `strace` (which inadvertently introduces delay to Vim's startup). It only occurs with foot and not when using tmux (tested on alacritty as well). This sequence in particular... ```^[[?12l^[[?25h^[[2;1H▽^[[6n^[[2;1H ^[[3;1H^[Pzz^[\^[[0%m^[[6n^[[3;1H``` ... appears early in Vim's initialization, and I hasten to wonder whether it could be related/misinterpreted based on the environment. I am not terribly familiar with how foot works, but perhaps this may assist someone in discovering why this may occur. I'm using the terminfo foot provides. I'll continue to try and uncover where this bug is coming from, but I first noticed it many months ago and I'm sure it has remained between versions of foot. Various forms of debugging haven't revealed much as there is no 'error,' but unpredictable behavior due to some confounding variable when using `sudo -e`. ### Relevant logs, stacktraces, etc. _No response_

craigbarnes commented 2024年06月21日 12:45:22 +02:00

sometimes Vim receives erroneous inputs immediately upon launching the program
...
Specifically, it appears to execute a 'normal mode paste' ("P") and inserts a number in the first position of the second line of the file

The first thing that comes to mind when I read that is that it sounds a lot like a mishandled query or query response. (削除) Especially since the sequence you mention includes the character P. (削除ここまで)

This sequence in particular...
^[[?12l^[[?25h^[[2;1H▽^[[6n^[[2;1H ^[[3;1H^[Pzz^[\^[[0%m^[[6n^[[3;1H

How did you observe that sequence? By intercepting the terminal I/O?

> sometimes Vim receives erroneous inputs immediately upon launching the program > ... > Specifically, it appears to execute a 'normal mode paste' ("P") and inserts a number in the first position of the second line of the file The first thing that comes to mind when I read that is that it sounds a lot like a mishandled query or query response. ~~Especially since the sequence you mention includes the character `P`.~~ >This sequence in particular... >`^[[?12l^[[?25h^[[2;1H▽^[[6n^[[2;1H ^[[3;1H^[Pzz^[\^[[0%m^[[6n^[[3;1H` How did you observe that sequence? By intercepting the terminal I/O?

craigbarnes commented 2024年06月21日 15:06:38 +02:00

Especially since the sequence you mention includes the character P

Looking a little closer at that sequence, this part of my previous reply can probably be disregarded. Rogue input at startup still sounds reminiscent of query/response parsing issues to me, but that sequence doesn't look like a likely culprit.

FWIW I tried to reproduce the issue in vim 9.1, by running the following (10 times):

SUDO_EDITOR=vim sudoedit /etc/xyz

...and nothing out of the ordinary happens.

... sometimes Vim receives erroneous inputs

How often is "sometimes"?

> Especially since the sequence you mention includes the character `P` Looking a little closer at that sequence, this part of my previous reply can probably be disregarded. Rogue input at startup still sounds reminiscent of query/response parsing issues to me, but that sequence doesn't look like a likely culprit. FWIW I tried to reproduce the issue in vim 9.1, by running the following (10 times): ```sh SUDO_EDITOR=vim sudoedit /etc/xyz ``` ...and nothing out of the ordinary happens. > ... _**sometimes**_ Vim receives erroneous inputs How often is "sometimes"?

craigbarnes commented 2024年06月21日 15:27:12 +02:00

... that sequence doesn't look like a likely culprit

Although it does look somewhat nonsensical. Specifically this part:

^[Pzz^[\^[[0%m

> ... that sequence doesn't look like a likely culprit Although it does look somewhat nonsensical. Specifically this part: > `^[Pzz^[\^[[0%m`

rhask commented 2024年06月21日 16:21:22 +02:00

@craigbarnes I observed the sequence using script -f <log_file> then doing what I wrote below. The video I've attached (28 seconds) shows the bug (and fortunately, I was able to reproduce it on the second attempt).

Here are the steps:

1. I opened vim with just vim (not sudoedit).
2. I typed some text and deleted all of it with ggVGd (thus it goes into some undo file) then closed the buffer with :q!.
3. I opened a file owned by root with sudo -e and the bug fails to manifest on the first attempt.
4. I opened a file owned by root with sudo -e again and immediately upon launch, the previously deleted text is inserted along with a number (in this case, "4," but sometimes "2" or "6") in the second row, position 1.
5. (Not necessary) I pushed u twice to show Vim received what appears to be two inputs.

Edit: I realize the vim command line isn't visible, but the only other command not shown is :q to exit the file and try again.

@craigbarnes I observed the sequence using `script -f <log_file>` then doing what I wrote below. The video I've attached (28 seconds) shows the bug (and fortunately, I was able to reproduce it on the second attempt). Here are the steps: 1. I opened vim with just `vim` (not `sudoedit`). 2. I typed some text and deleted all of it with `ggVGd` (thus it goes into some undo file) then closed the buffer with `:q!`. 3. I opened a file owned by root with `sudo -e` and the bug _fails to manifest on the first attempt_. 4. I opened a file owned by root with `sudo -e` again and immediately upon launch, the previously deleted text is inserted along with a number (in this case, "4," but sometimes "2" or "6") in the second row, position 1. 5. (Not necessary) I pushed `u` twice to show Vim received what appears to be two inputs. Edit: I realize the vim command line isn't visible, but the only other command not shown is `:q` to exit the file and try again.

rhask commented 2024年06月21日 16:39:41 +02:00

For clarity, that sequence appears regardless of whether the bug manifests... my curiosity is whether it's possible for Vim to misinterpret a query/response sequence as command inputs under "some circumstance" that happens occasionally (and I'm not sure what it would be, but the symptoms look like a race condition — potentially created by 'sudoedit' needing to 'set up' the environment?).

Edit: Sometimes is ~15% of the time if I had to guess... I could produce a real figure I suppose, but that's my sense from experience.

For clarity, that sequence appears regardless of whether the bug manifests... my curiosity is whether it's possible for Vim to misinterpret a query/response sequence as command inputs under "some circumstance" that happens occasionally (and I'm not sure what it would be, but the symptoms look like a race condition — potentially created by 'sudoedit' needing to 'set up' the environment?). Edit: Sometimes is ~15% of the time if I had to guess... I could produce a real figure I suppose, but that's my sense from experience.

dnkl commented 2024年06月21日 20:42:39 +02:00

Could perhaps be a duplicate of #1734?

Could perhaps be a duplicate of https://codeberg.org/dnkl/foot/issues/1734?

rhask commented 2024年06月21日 21:26:27 +02:00

I built from the master branch and tested; still occurs.

I built from the master branch and tested; still occurs.

rhask commented 2024年06月22日 03:04:31 +02:00

Here's where it seems that Pzz bit is coming from... this could be a red herring; I'm trying to cleverly deduce where a "P" input may have come from, but this is out of my reach. The obvious question is why this—if it is responsible—only causes a problem sometimes with sudoedit.

https://github.com/vim/vim/blob/master/src/term.c#L4144

Here's where it seems that Pzz bit is coming from... this could be a red herring; I'm trying to cleverly deduce where a "P" input may have come from, but this is out of my reach. The obvious question is why this—_if_ it is responsible—only causes a problem sometimes with sudoedit. https://github.com/vim/vim/blob/master/src/term.c#L4144

rhask commented 2024年06月22日 03:07:15 +02:00

Oh, I should have read the comment... this seems relevant:

	// We move the cursor to (2, 0), print a test sequence and then query
	// the current cursor position. If the terminal properly handles
	// unknown DCS string and CSI sequence with intermediate byte, the test
	// sequence is ignored and the cursor does not move. If the terminal
	// handles test sequence incorrectly, a garbage string is displayed and
	// the cursor does move.

Oh, I should have read the comment... this seems relevant: ``` // We move the cursor to (2, 0), print a test sequence and then query // the current cursor position. If the terminal properly handles // unknown DCS string and CSI sequence with intermediate byte, the test // sequence is ignored and the cursor does not move. If the terminal // handles test sequence incorrectly, a garbage string is displayed and // the cursor does move. ```

dnkl commented 2024年06月22日 08:18:57 +02:00

Maybe some weird interaction between vim, sudo and #453?

Maybe some weird interaction between vim, sudo and https://codeberg.org/dnkl/foot/issues/453?

rhask commented 2024年06月23日 14:46:59 +02:00

(削除) It seems likely. (削除ここまで) (e: further exploration below) If I understand correctly, the issue lies with sudo and other programs (besides vim) launched with sudo could be affected.

~~It seems likely.~~ (e: further exploration below) If I understand correctly, the issue lies with sudo and other programs (besides vim) launched with sudo could be affected.

rhask commented 2024年06月23日 20:36:58 +02:00

I tried using waitwinch, but the issue still manifests with waitwinch sudoedit <file>. If #453 is related only to new windows launched in Sway, then this is unlikely to be related.

I tried using [waitwinch](https://codeberg.org/craigbarnes/waitwinch), but the issue still manifests with `waitwinch sudoedit <file>`. If #453 is related only to new windows launched in Sway, then this is unlikely to be related.

rhask commented 2024年06月24日 23:20:28 +02:00

I narrowed down the culprit to ttimeoutlen=0 (which is mentioned here https://codeberg.org/dnkl/foot/wiki#enabling-disabling-ime-when-entering-leaving-insert-mode-in-vim). It seems that setting allows exiting insert mode in tmux without delay, but causes an issue without tmux and when TERM=foot if vim is launched via sudoedit.

I narrowed down the culprit to `ttimeoutlen=0` (which is mentioned here https://codeberg.org/dnkl/foot/wiki#enabling-disabling-ime-when-entering-leaving-insert-mode-in-vim). It seems that setting allows exiting insert mode in tmux without delay, but causes an issue without tmux and when TERM=foot if vim is launched via sudoedit.

rhask commented 2024年06月24日 23:30:29 +02:00

I'll add for anyone who may come across this in the future, this Vim configuration will solve the issue:

if $TERM == "tmux-256color"
 set ttimeoutlen=0
endif

I'll add for anyone who may come across this in the future, this Vim configuration will solve the issue: ```vim if $TERM == "tmux-256color" set ttimeoutlen=0 endif ```