bug#74220: invisible cursor

[Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On 2024-11-28 23:32, Eli Zaretskii wrote:
>> Date: Thu, 28 Nov 2024 13:45:49 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: stephen.berman@gmx.net, bug-gnu-emacs@gnu.org, rpluim@gmail.com,
>>  gerd.moellmann@gmail.com, 74220@debbugs.gnu.org, ampinkas@gmail.com
>> 
>> >> But is this the right fix? CAP_SYS_ADMIN grants many dangerous
>> >> capabilities on Linux. An alternative fix would be to update redisplay
>> >> on terminals to draw the mouse cursor. Perhaps this is what is done on
>> >> other OSes? I would like guidance here on which path is recommended.
>> >
>> > Let's first understand the problem better.
>> >
>> > (And I'm guessing that by "cursor" you mean "mouse pointer"?)
>> 
>> Here's some more specifics:
>> 
>> Emacs draws the mouse pointer in handle_one_term_event in term.c. It
>> does this by calling GPM_DrawPointer() with the intended x and y. This
>> code is pretty old, a blame says it was from 2007.
>> 
>> GPM_DrawPointer is just a macro, see the GitHub mirror:
>> https://github.com/telmich/gpm/blob/master/src/headers/gpm.h#L235. 
>> This
>> calls a Linux ioctl() to draw the cursor. This code is also pretty 
>> old,
>> a blame says it was from 2005.
>> 
>> The Linux ioctl() is called as follows, if it used symbolic constants
>> and a struct instead of magic byte values:
>> 
>> struct {
>>      char  subcode;
>>      short xs, ys, xe, ye;
>>      short sel_mode;
>> } gpmbuf;
>> 
>> gpmbuf.subcode = TIOCL_SETSEL; // 2
>> gpmbuf.xs = gpmbuf.xe = x;
>> gpmbuf.ys = gpmbuf.ye = y;
>> gpmbuf.selmode = TIOCL_SELPOINTER; //3
>> ioctl(fd, TIOCLINUX, &gpmbuf);
> 
> Thanks.  I think I see a far-away light at the end of the tunnel, but
> I'm not yet sure whether it's daylight or the proverbial train.
> What's missing in the above is the relation to "kernel selection
> buffer".  I'm guessing that TIOCL_SETSEL is "setting the kernel
> selection buffer", given its name, but I'm not sure.

Yes, exactly.

The same TIOCL_SETSEL is also used for actually setting the selection. 
If selmode is TIOCL_SELCHAR, TIOCL_SELWORD, or TIOCL_SELLINE then the 
region from start to end is copied into a kernel-level buffer that can 
be pasted with TIOCL_PASTESEL.

The same TIOCL_SETSEL is also used for changes that appear to be 
completely unrelated to the kernel managed selection buffer.  Namely the 
following three modes: TIOCL_SELPOINTER, TIOCL_SELCLEAR (it only 
controls visuals), TIOCL_SELMOUSEREPORT (it reports the selection start 
coordinate).

>> This adds one other solution -- I could see if it is reasonable for 
>> the
>> Linux kernel to not protect TIOCL_SELPOINTER while protecting the rest
>> of TIOCL_SETSEL. I'm a bit nervous here as I don't understand the
>> security implications of SELPOINTER vs other selections, though on 
>> first
>> glance it seems reasonable.
> 
> I actually wonder about something else: did the kernel developers
> _intend_ to break mouse pointer drawing by GPM? or maybe they intend
> to deprecate GPM as a whole?  I mean, Emacs is presumably not the only
> application that uses GPM, and what you describe above is part of GPM
> code, right?  So GPM should be now broken for all the other
> applications as well, right?

GPM was explicitly intended to be supported from the Linux kernel 
discussions. 
https://lwn.net/ml/kernel-hardening/2023082203-slackness-sworn-2c80@gregkh/.

I think Emacs is a special snowflake in that it doesn't (possibly 
can't?) rely on the GPM daemon drawing the mouse pointer. I did not see 
any other app with this problem. I tested Vim, Midnight Commander, Nano, 
and Bash. I don't know what is special about Emacs here. Perhaps the 
character under the mouse pointer is treated special in redisplay? Not 
sure.

I will reach out to the kernel mailing list and see if they are ok 
relaxing the check and fixing this on their end.

   -- MJF