Having looked into this, I think "exec-formatted" and "exec-selectable".
are the kind of mis-designed anti-security features I don't want in xterm
The idea of this is very much against the idea of priv-sep or priv-drop.
If a command is supposed to be capable of starting another fresh command
at any time in the future, then it obviously cannot drop all it's
capabilities, therefore it is not privdrop. It must retain the ability
to spawn new commands, but that is precisely what we don't want xterm to
be able to do.
This is handled optionally, by users configuring it, but the users are not
warned that this makes their xterm less self-protecting against the excalation
of bugs (which will always exist in a program as large as xterm)
We deleted the ! command from less(1), and similar spawning-features
from other commands, with the same justification, and thus far our users
have adapted and there have been no complaints.
I would be super-happy if this chunk was deleted from xterm:
{
String data = NULL;
getKeymapResources(SHELL_OF(term), "vt100", "VT100", XtRString, &data,
sizeof(dat\
a));
if (data &&
(strstr(data, "exec-formatted") || strstr(data,
"exec-selectable"))) {
if (pledge("stdio rpath wpath id proc exec tty", NULL) == -1) {
xtermWarning("pledge\n");
exit(1);
}
of course, also manual page-updates to inform users that these 3 features which
use re-exec (also "spawn-new-terminal") are unsupported, plus why we did so.
Because any user using that feature is running a less-secure xterm than the
alternative which has a bunch of unveil() plus
if (pledge("stdio rpath wpath id proc tty", NULL) == -1) {
I don't know why xterm lacks third call to pledge to drop "proc". You can
wait4(2) or killpg(2) from "stdio". Is there a reason?
