Am 19.04.2012 09:25, schrieb Janne Blomqvist:
On Thu, Apr 19, 2012 at 01:45, Manfred Schwarb<manfre...@gmx.ch> 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 https://bugs.gentoo.org/show_bug.cgi?id=332927, 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...
Manfred
