* Overriding "builtin" @ 2022-08-12 1:18 Zach Riggle 2022-08-12 2:24 ` Đoàn Trần Công Danh 0 siblings, 1 reply; 14+ messages in thread From: Zach Riggle @ 2022-08-12 1:18 UTC (permalink / raw) To: Zsh Users [-- Attachment #1: Type: text/plain, Size: 317 bytes --] I recently learned that 'builtin' can be overridden with a function. Neat for some silly tricks! However, is there a way to save / restore 'builtin' such that it can be restored? All that I can think of is 'unfunction builtin', but 'unfunction' itself can be overridden with a function. Any ideas? *Zach Riggle* [-- Attachment #2: Type: text/html, Size: 629 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 1:18 Overriding "builtin" Zach Riggle @ 2022-08-12 2:24 ` Đoàn Trần Công Danh 2022-08-12 7:12 ` Daniel Shahaf 0 siblings, 1 reply; 14+ messages in thread From: Đoàn Trần Công Danh @ 2022-08-12 2:24 UTC (permalink / raw) To: Zach Riggle; +Cc: Zsh Users On 2022-08-11 20:18:49-0500, Zach Riggle <zachriggle@gmail.com> wrote: > I recently learned that 'builtin' can be overridden with a function. Neat > for some silly tricks! > > However, is there a way to save / restore 'builtin' such that it can be > restored? > > All that I can think of is 'unfunction builtin', but 'unfunction' itself > can be overridden with a function. You can run original builtin with "builtin". e.g.: echo() { printf '++%s\n' "$@"; } echo this will run function builtin echo this will run builtin -- Danh ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 2:24 ` Đoàn Trần Công Danh @ 2022-08-12 7:12 ` Daniel Shahaf 2022-08-12 7:57 ` Stephane Chazelas 2022-08-12 13:54 ` Thomas Lauer 0 siblings, 2 replies; 14+ messages in thread From: Daniel Shahaf @ 2022-08-12 7:12 UTC (permalink / raw) To: Đoàn Trần Công Danh, Zach Riggle; +Cc: Zsh Users Đoàn Trần Công Danh wrote on Fri, 12 Aug 2022 02:24 +00:00: > On 2022-08-11 20:18:49-0500, Zach Riggle <zachriggle@gmail.com> wrote: >> I recently learned that 'builtin' can be overridden with a function. Neat >> for some silly tricks! >> >> However, is there a way to save / restore 'builtin' such that it can be >> restored? >> >> All that I can think of is 'unfunction builtin', but 'unfunction' itself >> can be overridden with a function. > «unset 'functions[unfunction]'», provided (zsh/parameter is available and) someone hasn't created an unset() function as well. > You can run original builtin with "builtin". > > e.g.: > > echo() { printf '++%s\n' "$@"; } > echo this will run function > builtin echo this will run builtin No, he can't, because in his case that'd be a bottomless recursive call (= an infinite loop). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 7:12 ` Daniel Shahaf @ 2022-08-12 7:57 ` Stephane Chazelas 2022-08-12 18:42 ` Lawrence Velázquez 2022-08-12 13:54 ` Thomas Lauer 1 sibling, 1 reply; 14+ messages in thread From: Stephane Chazelas @ 2022-08-12 7:57 UTC (permalink / raw) To: Daniel Shahaf Cc: Đoàn Trần Công Danh, Zach Riggle, Zsh Users On 2022-08-12 08:12, Daniel Shahaf wrote: [...] > «unset 'functions[unfunction]'», provided (zsh/parameter is available > and) someone hasn't created an unset() function as well. [...] Or the standard "unset -f builtin" Or functions=() (or exec zsh -f) Or builtin() { echo my builtin wrapper set -o localoptions -o posixbuiltins command builtin "$@" } (though that affects the behaviour of the builtin called by builtin. -- Stephane ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 7:57 ` Stephane Chazelas @ 2022-08-12 18:42 ` Lawrence Velázquez 2022-08-12 19:33 ` Zach Riggle 0 siblings, 1 reply; 14+ messages in thread From: Lawrence Velázquez @ 2022-08-12 18:42 UTC (permalink / raw) To: Zach Riggle Cc: Stephane Chazelas, Daniel Shahaf, Đoàn Trần Công Danh, zsh-users On Fri, Aug 12, 2022, at 3:57 AM, Stephane Chazelas wrote: > On 2022-08-12 08:12, Daniel Shahaf wrote: > [...] >> «unset 'functions[unfunction]'», provided (zsh/parameter is available >> and) someone hasn't created an unset() function as well. > [...] > > Or the standard "unset -f builtin" > > Or functions=() > > (or exec zsh -f) > > Or > > builtin() { > echo my builtin wrapper > set -o localoptions -o posixbuiltins > command builtin "$@" > } Or ''unhash -f builtin''. I (perhaps overzealously) interpreted the original question as asking for a method that is impervious to interference from *any* function (and maybe alias?) definition. But if you've broken your shell so hard that *none* of these suggestions works, then, as they say in the IRC channel, you get to keep the pieces. -- vq ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 18:42 ` Lawrence Velázquez @ 2022-08-12 19:33 ` Zach Riggle 2022-08-12 20:35 ` Lawrence Velázquez 2022-08-12 20:54 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Zach Riggle @ 2022-08-12 19:33 UTC (permalink / raw) To: Lawrence Velázquez Cc: Stephane Chazelas, Daniel Shahaf, Đoàn Trần Công Danh, zsh-users [-- Attachment #1: Type: text/plain, Size: 1180 bytes --] Wouldn't the above also break for this? function unhash() { ... } It would be nice if we could add a feature such that the "builtin" identifier cannot be overloaded. *Zach Riggle* On Fri, Aug 12, 2022 at 1:43 PM Lawrence Velázquez <larryv@zsh.org> wrote: > On Fri, Aug 12, 2022, at 3:57 AM, Stephane Chazelas wrote: > > On 2022-08-12 08:12, Daniel Shahaf wrote: > > [...] > >> «unset 'functions[unfunction]'», provided (zsh/parameter is available > >> and) someone hasn't created an unset() function as well. > > [...] > > > > Or the standard "unset -f builtin" > > > > Or functions=() > > > > (or exec zsh -f) > > > > Or > > > > builtin() { > > echo my builtin wrapper > > set -o localoptions -o posixbuiltins > > command builtin "$@" > > } > > Or ''unhash -f builtin''. > > I (perhaps overzealously) interpreted the original question as > asking for a method that is impervious to interference from *any* > function (and maybe alias?) definition. But if you've broken your > shell so hard that *none* of these suggestions works, then, as they > say in the IRC channel, you get to keep the pieces. > > -- > vq > [-- Attachment #2: Type: text/html, Size: 1886 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 19:33 ` Zach Riggle @ 2022-08-12 20:35 ` Lawrence Velázquez 2022-08-12 20:54 ` Bart Schaefer 1 sibling, 0 replies; 14+ messages in thread From: Lawrence Velázquez @ 2022-08-12 20:35 UTC (permalink / raw) To: Zach Riggle Cc: Stephane Chazelas, Daniel Shahaf, Đoàn Trần Công Danh, zsh-users On Fri, Aug 12, 2022, at 3:33 PM, Zach Riggle wrote: > Wouldn't the above also break for this? > > function unhash() { ... } Yes. I did not mean to imply that my suggestion was bulletproof, only to opine that seeking such a method is a fool's errand. You can take reasonable precautions, but at some point you are tilting at windmills. > It would be nice if we could add a feature such that the "builtin" > identifier cannot be overloaded. I think this is a solution in search of a problem. -- vq ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 19:33 ` Zach Riggle 2022-08-12 20:35 ` Lawrence Velázquez @ 2022-08-12 20:54 ` Bart Schaefer 2022-08-29 20:42 ` Zach Riggle 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2022-08-12 20:54 UTC (permalink / raw) To: Zach Riggle; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 20:54 ` Bart Schaefer @ 2022-08-29 20:42 ` Zach Riggle 2022-08-30 1:31 ` Bart Schaefer 2022-08-30 1:41 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Zach Riggle @ 2022-08-29 20:42 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users [-- Attachment #1: Type: text/plain, Size: 1766 bytes --] 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. > [-- Attachment #2: Type: text/html, Size: 2992 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-29 20:42 ` Zach Riggle @ 2022-08-30 1:31 ` Bart Schaefer 2022-08-30 1:41 ` Bart Schaefer 1 sibling, 0 replies; 14+ messages in thread From: Bart Schaefer @ 2022-08-30 1:31 UTC (permalink / raw) To: Zach Riggle; +Cc: zsh-users On Mon, Aug 29, 2022 at 1:42 PM Zach Riggle <zachriggle@gmail.com> wrote: > > 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)? On my Ubuntu at least, =sudo is /bin/sudo not /usr/bin/sudo ... I suspect if /usr/bin preceded /bin in $PATH, you would not see the above behavior. I certainly can't reproduce similar behavior when using a function named /bin/echo to attempt it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-29 20:42 ` Zach Riggle 2022-08-30 1:31 ` Bart Schaefer @ 2022-08-30 1:41 ` Bart Schaefer 1 sibling, 0 replies; 14+ messages in thread From: Bart Schaefer @ 2022-08-30 1:41 UTC (permalink / raw) To: Zach Riggle; +Cc: zsh-users On Mon, Aug 29, 2022 at 1:42 PM Zach Riggle <zachriggle@gmail.com> wrote: > > 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. You can always use relative paths. E.g. /../././../usr/bin/sudo /usr/./bin/./sudo etc. it would be ... impractical ... to replace all possible combinations of this with functions. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 7:12 ` Daniel Shahaf 2022-08-12 7:57 ` Stephane Chazelas @ 2022-08-12 13:54 ` Thomas Lauer 2022-08-12 15:41 ` Bart Schaefer 1 sibling, 1 reply; 14+ messages in thread From: Thomas Lauer @ 2022-08-12 13:54 UTC (permalink / raw) To: Daniel Shahaf; +Cc: ?oàn Tr?n Công Danh, Zach Riggle, Zsh Users From: "Daniel Shahaf" <d.s@daniel.shahaf.name> Date: Fri, 12 Aug 2022 07:12:56 +0000 > ?oàn Tr?n Công Danh wrote on Fri, 12 Aug 2022 02:24 +00:00: > > On 2022-08-11 20:18:49-0500, Zach Riggle <zachriggle@gmail.com> wrote: > >> I recently learned that 'builtin' can be overridden with a function. Neat > >> for some silly tricks! > >> > >> However, is there a way to save / restore 'builtin' such that it can be > >> restored? > >> > >> All that I can think of is 'unfunction builtin', but 'unfunction' itself > >> can be overridden with a function. > > > > «unset 'functions[unfunction]'», provided (zsh/parameter is available > and) someone hasn't created an unset() function as well. > > > You can run original builtin with "builtin". > > > > e.g.: > > > > echo() { printf '++%s\n' "$@"; } > > echo this will run function > > builtin echo this will run builtin > > No, he can't, because in his case that'd be a bottomless recursive call > (= an infinite loop). Hm... this works here as I'd expect, but since you said "in his case" there may be something that turns that into a non-terminating recursion just for Zach's case. But what? (Always eager to learn something :-/ ) Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 13:54 ` Thomas Lauer @ 2022-08-12 15:41 ` Bart Schaefer 2022-08-12 16:07 ` Thomas Lauer 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2022-08-12 15:41 UTC (permalink / raw) To: Thomas Lauer; +Cc: Zsh Users On Fri, Aug 12, 2022 at 6:54 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > Hm... this works here as I'd expect, but since you said "in his case" > there may be something that turns that into a non-terminating recursion > just for Zach's case. But what? (Always eager to learn something :-/ ) Zach's case is that "builtin" is itself a function. builtin() { echo HA HA no builtins here; "$@" } ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Overriding "builtin" 2022-08-12 15:41 ` Bart Schaefer @ 2022-08-12 16:07 ` Thomas Lauer 0 siblings, 0 replies; 14+ messages in thread From: Thomas Lauer @ 2022-08-12 16:07 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users ----original message---- From: Bart Schaefer <schaefer@brasslantern.com> Date: Fri, 12 Aug 2022 08:41:25 -0700 > On Fri, Aug 12, 2022 at 6:54 AM Thomas Lauer <thomas.lauer@virgin.net> wrote: > > > > Hm... this works here as I'd expect, but since you said "in his case" > > there may be something that turns that into a non-terminating recursion > > just for Zach's case. But what? (Always eager to learn something :-/ ) > > Zach's case is that "builtin" is itself a function. > > builtin() { echo HA HA no builtins here; "$@" } Got it. THX Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-08-30 1:42 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-12 1:18 Overriding "builtin" Zach Riggle 2022-08-12 2:24 ` Đoàn Trần Công Danh 2022-08-12 7:12 ` Daniel Shahaf 2022-08-12 7:57 ` Stephane Chazelas 2022-08-12 18:42 ` Lawrence Velázquez 2022-08-12 19:33 ` Zach Riggle 2022-08-12 20:35 ` Lawrence Velázquez 2022-08-12 20:54 ` Bart Schaefer 2022-08-29 20:42 ` Zach Riggle 2022-08-30 1:31 ` Bart Schaefer 2022-08-30 1:41 ` Bart Schaefer 2022-08-12 13:54 ` Thomas Lauer 2022-08-12 15:41 ` Bart Schaefer 2022-08-12 16:07 ` Thomas Lauer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).