On Mon, 9 Apr 2018, Takashi Iwai wrote:
On Sun, 08 Apr 2018 18:13:43 +0200, Mark Hills wrote:
I just came up against the patch below; it prevents useful snippets of alsa-conf like this:
@hooks [ { func load files [ "~/.asoundrc-$HOSTNAME" ] errors false } ]
as the evalutation of all but "~" has been removed.
Seems like removal of a perfectly good feature in the name of security; because wordexp()
is not used (and should not be used) on data originating from an untrusted source
is already used with WRDE_NOCMD, which the same POSIX spec documents as:
"The WRDE_NOCMD flag is provided for applications that, for security or other reasons, want to prevent a user from executing shell commands."
on glibc can be seen (with strace) not to execute other commands
If one is to treat the POSIX doc as gospel (as cited by the patch) the cause of firefox (circa July 2017) not working would actually be that musl does not honour WRDE_NOCMD to the letter. I agree the spec of wordexp() could be more useful, though.
Also, hypothesising the attacks of an already-compromised application would get into a sticky conversation about the thread safety of getenv("HOME") (and associated buffer wrangling) vs. a library function being used for its intended purpose.
In practice, Firefox may have moved on here (no ALSA support anymore) so should quirks of its sandbox be driving this?
What's wrong with you building the alsa-lib with --with-wordexp if you prefer having that behavior?
Practically, I must build custom packages for all machines (some I do not control, eg. my employer's)
My case here is both that the default behaviour should not have changed; and that the security rationale offered here is misleading.