Consensus on allowing tunables to use GLIBC_* namespace env vars.

[Florian Weimer]

On 09/10/2015 07:40 PM, Siddhesh Poyarekar wrote:

> I believe this will happen regardless of whether we use a singled envvar or
> multiple envvars because the space required for that data will be more or
> less the same.  For performance tunables, the recommended method for
> measurement in such a scenario would be to keep the tunable defined and
> change the value to determine which value is better, i.e. explicitly specify
> even the default value so that it produces a similar stack alignment.

Yes, that looks like an appropriate workaround.

>> LD_* might benefit from some existing security filters.  Maybe that's
>> sufficient for staying within that namespace?
> 
> I don't understand, could you please rephrase?  LD_* already has some
> security filters in place, i.e. a lot of them are scrubbed away for setuid
> binaries.  Are you suggesting doing similar for GLIBC_* variables too?  I
> don't see why not.

Using LD_* would make it quite likely that filters outside glibc cover
these variables, removing the across a trust boundary.  (Using LC_*
would have the opposite effect, increasing the likelihood that
environment variables are passed through.)

I have no particular opinion either way (LD_* vs GLIBC_*), I just wanted
to raise it as an additional point worth considering.

-- 
Florian Weimer / Red Hat Product Security