3 ms·

Seems it's very old code. New Libc doesn't do this. This is Libc from Mojave: http://xr.anadoxin.org/source/xref/macos-10.14-mojave/Libc-1272.200.26/gen/FreeBS

Seems it's very old code. New Libc doesn't do this. This is Libc from Mojave: http://xr.anadoxin.org/source/xref/macos-10.14-mojave/Libc-1272.200.26/gen/FreeBSD/wordexp.c#105 http://xr.anadoxin.org/source/xref/macos-10.14-mojave/Libc-1... The 'perl' code was a part of Libc v825.24, which seems to be included between 10.7 (Lion) and 10.8 (Mountain Lion). Of course I still find it hilarious that even the old code did that!

opencl 8y ago
The current version replaces the perl subprocess with an sh subprocess. Doesn't seem like much of an improvement.
- anyfoo 8y ago
  Well, wordexp's purpose is literally to "perform shell-style word expansions", as quoted from the man page. It even supports command substitution if you don't pass WRDE_CMDSUB. So really, the entire premise of that POSIX function is horrible[1]. Just like system(), which also explicitly executes the given command line using the shell. These functions are not safe to use with untrusted input (e.g. remotely), ever. EDIT: [1] But arguably only as horrible as calling out to the shell is in general. If you e.g. use it as part of a shell utility that assumes full POSIX-permissioned access to your user anyway, it's not unreasonable because there isn't any privilege escalation at all. Though I'd argue that in the case of system() it's probably more clear to the developer that a shell callout is happening. And also, that the "shell-style" expansion performed here is kinda muddily defined.
- AHTERIX5000 8y ago
  OTOH the standard itself mentions implementing the function using shell in a subprocess [1]. POSIX is full of nastiness such as this, hopefully not too many maintained & used software actually needs wordexp. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/w...

opencl 8y ago

The current version replaces the perl subprocess with an sh subprocess. Doesn't seem like much of an improvement.

anyfoo 8y ago
Well, wordexp's purpose is literally to "perform shell-style word expansions", as quoted from the man page. It even supports command substitution if you don't pass WRDE_CMDSUB. So really, the entire premise of that POSIX function is horrible[1]. Just like system(), which also explicitly executes the given command line using the shell. These functions are not safe to use with untrusted input (e.g. remotely), ever. EDIT: [1] But arguably only as horrible as calling out to the shell is in general. If you e.g. use it as part of a shell utility that assumes full POSIX-permissioned access to your user anyway, it's not unreasonable because there isn't any privilege escalation at all. Though I'd argue that in the case of system() it's probably more clear to the developer that a shell callout is happening. And also, that the "shell-style" expansion performed here is kinda muddily defined.
AHTERIX5000 8y ago
OTOH the standard itself mentions implementing the function using shell in a subprocess [1]. POSIX is full of nastiness such as this, hopefully not too many maintained & used software actually needs wordexp. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/w...