This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 11 Sep 2015 11:28:14 +0200
- Subject: Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- Authentication-results: sourceware.org; auth=none
- References: <55E90AA9 dot 30909 at redhat dot com> <55F0225B dot 7060502 at redhat dot com> <1468134304 dot 15507164 dot 1441906848321 dot JavaMail dot zimbra at redhat dot com>
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