RE: Re: Security issue in Zsh restricted mode (zsh -r) – escape via history built‑ins

[zeurkous@xxxxxxxxxxxxxxx]

Oh, let's not forget to note...

On Sun, 01 Feb 2026 13:10:17 +0100, Oliver Kiddle <opk@xxxxxxx> wrote:
> Yes, sorry. Though I notice that the documentation specifically mentions
> that the system module should be disabled for restricted mode so if
> we do want to "fix" restricted mode, this part is not necessary. We
> could perhaps just recommend disabling zcompile in the documentation.
> Variables like TMPPREFIX are problematic, though. Many of the variables
> used by the runtime loader are also a major flaw with the concept behind
> a restricted shell. If writing to files is to be blocked then Linux's
> LD_DEBUG_OUTPUT gets around that. LD_PRELOAD or LD_LIBRARY_PATH may make
> for an easier escape route. It's not the shell's job to block these off
> and they vary considerably across operating systems.

...that the LD_* mess can of course be gotten around by linking the
shell statically. But as you pointed out: there are more problematic
variables out there. Me supposes that '-r' made much more sense back
when the environment was small and the shell maintainer could be
immediately advised of any changes, to the rest of the system, that 
might be used to bypass the shell-imposed restrictions.

As me sees it: the only way to salvage '-r' would be to make the
option heavily configurable so that the restrictions may match the
reality on each particular system. That'd be a bit of a project, and
the resulting configuration files could be cumbersome to maintain.

        --zeurkous. 

-- 
Friggin' Machines!