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

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...


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