This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, libfortran] Fix handling of temporary files

On Thu, Apr 19, 2012 at 11:52, Manfred Schwarb <> wrote:
> Am 19.04.2012 09:25, schrieb Janne Blomqvist:
>> On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb<> Âwrote:
>>> Hi Janne,
>>>> - If the program is privileged, we shouldn't trust path style
>>>> environment variables. The patch fixes this for TMPDIR and also for
>>>> the logic figuring out where addr2line is.
>>> I did not test it, but if I remember right, the use of geteuid() and
>>> friends
>>> does prevent static compilation, resp. static compilation does seem
>>> to work, but it needs a matched dynamic library nonetheless,
>>> which means if you relocate your statically linked program to another
>>> box with differing glibc, you get runtime errors?
>>> Or is the use of static programs already broken so it does not matter?
>>> If this security feature would prevent use of static programs, it would
>>> not be worth it, I think.
>> getuid and friends are already used in other parts of the runtime
>> library, so if static linking to glibc is broken it was broken before
>> as well.
>> The Glibc FAQ says:
>> 2.22. Â Even statically linked programs need some shared libraries
>> Â Â Â Âwhich is not acceptable for me. ÂWhat can I do?
>> {AJ} NSS (for details just type `info libc "Name Service Switch"') won't
>> work properly without shared libraries. ÂNSS allows using different
>> services
>> (e.g. NIS, files, db, hesiod) by just changing one configuration file
>> (/etc/nsswitch.conf) without relinking any programs. ÂThe only
>> disadvantage
>> is that now static libraries need to access shared libraries. ÂThis is
>> handled transparently by the GNU C library.
>> I'm not sure of the details of what happens, or under which exact
>> circumstances it works or not, when one runs a statically linked
>> program on another machine with a different glibc version.
> The nasty thing is, the runtime error does not happen at program start, but
> at the point of actual invocation of the *uid call. So this may come as
> a real surprise for the user if such functions are seldom called in the
> binary, e.g. in some error path.
> And the really ugly thing is, there seems to be an incompatible break
> between
> glibc 2.11 and 2.12 in this very NSS stuff.
> I recently stumbled over,
> when
> the provider decided to upgrade glibc on the server (sic!).
> [ And, it was a c-program that was crashing, my static fortran programs were
> still running fine ]
> As traditionally a lot of fortran code is statically compiled, I just wanted
> to make aware that the more of such calls are added, the more likely users
> will
> get surprises.
> I guess relocation of binaries to other boxes is not uncommon in the HPC
> sector,
> and having a crash after some weeks of runtime due to this is not really
> funny...

That shouldn't be an issue then as with the patch __secure_getenv is
called during library initialization, so if it's going to crash it
will crash immediately.

Also, I suspect getuid and friends are not actually part of the NSS
stuff. The uid/gid/euid/egid are maintained for each process by the
kernel, and NSS only handles translation to/from the numeric id's to
string values, IP address lookup and so forth.

Janne Blomqvist

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]