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

As an aside, on targets with glibc the patch uses __secure_getenv
rather than directly calling the getuid etc. functions. But that
essentially just moves the problem into glibc so I'm not sure if the
end result is any different.

Also, it seems Solaris no longer ships a static libc at all:

Anyways, I'd rather keep this security feature as currently this
should be easy to exploit, making linking to libgfortran from any
SUID/SGID binary quite dangerous (I don't know of any such program,
but you never know what crazy things people come up with..).

Janne Blomqvist

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