utmp and wtmp files at startup. real-uid / effective-uid flipping was
used to cleanup the records in these two files at logout-time. Over
time it was recognized that setuid root is too dangerous, later on
even uid flipping became an unacceptable practice (because an attacker
who finds a bug will simply flip the uid back to root before
continuing exploitation). Some OS's helped xterm (and other similar
login-related tooling) by making utmp writeable by a new utmp group,
but most did not do the same for wtmp. xterm started using this new
utmp gid, and the wtmp code moved to "try, and if it fails, ignore the
failure".
The obvious way to use this uid is for xterm to open the utmp file for
write (early on), discard the egid, and keep the file descriptor
around until utmp cleanup at termination. 10-20 lines of code, maybe.
But no,.... that's not what happened.
The previous setuid root flipping code (which is nearly a hundred
lines of #ifdef-wrapped code for portability reasons) was copied and
repurposed by adding new #ifdef code for setgid utmp flipping, and
thus nearly a hundred lines of #ifdef-wrapped code was added). setgid
flipping has less severe security risks than setuid flipping, but it
is remains an excessively strong and unneccessary power (compared to a
single writeable fd).
When pledge() arrived on the scene, "wpath" was required so that the
utmp file could be opened late, and "id" was required to support egid
flipping. unveil() arrived on the scene, and the utmp path was added
to the list of viable paths, once again not considering that an incorrect
approach was being taken by the code.
I tried rewriting the portable USE_UTMP_SETGID code to follow the
open-drop-reuse-fd approach, to help out upstream xterm, but it is such
a brain-melting shitshow I gave up, we'll have a (small) intrusive patch
which opens utmp early, drops the gid, and reuses the fd later on.
Maybe upstream will take care of this eventually to reduce the risk of
egid other operating systems.
ok matthieu, much feedback from millert
This code is not compiled on OpenBSD so the shipped xterm are not
vulnerable to this (which is CVE-2022-24130)
Committing the fix in case someone uses this for builds with sixel enabled.
original from naddy@:
> Don't declare variables as "unsigned char *" that are passed to
> functions that take "char *" arguments. Where such chars are
> assigned to int or passed to ctype functions, explicitly cast them
> to unsigned char.
>
> For OpenBSD's clang, -Wpointer-sign has been disabled by default,
> but when the parse.y code was built elsewhere, the compiler would
> complain.
>
> With help from millert@
> ok benno@ deraadt@
If you had no .Xauthority, you needed to log in twice, because xenodm
created .Xauthority after your 1st session failed.
problem found by solene@
ok matthieu@ deraadt@
Only in (default) case where there are no exec-formatted or
exec-selected resources set. In those case the commands and their
arguments could be anywhere.
CharWidth is a conditional wrapper that assumes that all wide characters
in the range 32-126 and 160-255) are latin-1 characters and are identical
with the unicode (UTF-8) codepoints and result in a width of 1.
This is correct in so far that the names of these code-points are
identical, but for SHY (soft-hyphen) the explanation of how it should be
used differs between unicode and latin-1. Latin-1 assumes that it's always
displayed, for unicode it should only be displayed after local grammar
rules apply.
This wrapper got introduced in xterm #334 and is on the short-list of Thomas
Dickey to fix. Since we don't know when the next release is going to be,
commit this one now, so we have it fixed before 7.0.
Originally discrepency between xterm and wcwidth(3) pointed out by Lauri
Tirkkonen (lauri <at> hacktheplanet <dot> fi).
OK matthieu@
Xsetup, Xstartup, Xsession and Xreset scripts and remove the sample code
that don't match the reality.
Also, while there mention more files used, including ~/.xsession-errors.
Based on a report from Laurence Tratt with corrections from jmc@
Spawn a window, maximize it in any way, move the cursor to a window border
that is not on the screen's edge and unmaximize again: While the window
goes back the cursor stays at the screen's edge, i.e. focus is lost to the
underlaying window.
Moving, resizing, tiling or snapping windows in any way always moves the
cursor along iff needed, e.g. using MS-[hjkl] to move a small window from
the center to the edge keeps the cursor within window borders -- no matter
what you do with the keyboard, focus stays on that window.
Make CM-f, CM-m, CM-equal and CMS-equal (default bindings) for toggling
full-screen mode, maximization, vertical maximization and horizontal
maximization of the current window drag the cursor along if needed as well.
OK okan kmos dv
