1576006 - Firefox doesn't set HAVE_SECURE_GETENV correctly for NSPR build

Status: NEW

(Firefox Build System :: General, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Bug 1194678 added PR_GetEnvSecure, which is a locked (like PR_GetEnv) version of secure_getenv, which is a glibc extension for cases like log file paths where code running with elevated privileges (e.g., setuid/setgid) needs to ignore the untrustworthy environment to prevent privilege escalation.

NSPR's configure script detects the function, but Firefox's build glue doesn't set those defines.

As a result, Firefox on glibc gets the fallback implementation, which checks if the real uid/gid match the effective ones. Normally this isn't a problem, because as far as I'm aware no part of Firefox would be installed in a way that would observe the difference (e.g., with file capabilities), or even with regular setuid/setgid bits, but there is a slight problem for sandboxing: the policy for GeckoMediaPlugins doesn't allow get*id, because nothing so far has needed it, but we'd need to change that to use NSS in the clearkey reference CDM.

Fixing this isn't entirely trivial: RHEL 5 and 6 appear to have a glibc that's too old to have it (unless it was backported?), and musl libc only got support for it earlier this month, so we'd want to do an autoconf-like check.

Comment 1

[Florian Weimer]

Older glibc versions provide __secure_getenv instead of getenv. You can use the older symbol to preserve backwards compatibility:

https://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Thanks for the pointer. NSPR already handles both names, but Firefox would need to do something similar to those autoconf checks to set the right HAVE_ define.

My understanding is that we're trying to reduce the use of autoconf in Firefox proper, in favor of moz.configure Python scripting, but I don't know what tools it has for this or where its documentation is hiding.