Following up on this a bit, it seems that if your Zsh code is executing in
a malicious environment (e.g. has done "function /usr/bin/sudo() { echo lol
}") is to use a non-qualified path with the "=" prefix.

$ function /usr/bin/sudo { echo lol }


$ /usr/bin/sudo whoami
lol


$ =/usr/bin/sudo whoami
lol


$ =sudo whoami
root


Why does "=sudo" do the correct thing (assuming a sane $PATH, and executes
/usr/bin/sudo), but "=/usr/bin/sudo" does the wrong thing (i.e., execute
the function)?

Assume "builtin", "command", "exec", etc. have all been overwritten with
functions.

Since the environment is malicious, $PATH also cannot be trusted -- I
thought "=" might be a way to guarantee that an executable at a specific
absolute path does get executed instead of something else (alias, function,
autoloadable, etc) but it doesn't work when specifying the full path.

*Zach Riggle*


On Fri, Aug 12, 2022 at 3:54 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Fri, Aug 12, 2022 at 12:33 PM Zach Riggle <zachriggle@gmail.com> wrote:
> >
> > It would be nice if we could add a feature such that the "builtin"
> identifier cannot be overloaded.
>
> This isn't really feasible, given that we have e.g. "disable builtin"
> and "alias builtin=...".
>
> That does point out that another approach to bypassing the function is
>  disable -f builtin
> which is pretty nice in that it leaves the function defined but
> inaccessible.  Of course one can still "disable disable" as well.
>
> I can't imagine why anyone would do this, but of course
>
> disable -rm \*
> disable -m \*
>
> leaves the shell able to only to execute pipelines built from external
> commands.  Preceded with a few "alias -g" of separators, you end up
> limited to simple external commands.
>