SEO

I just completed upgrading three systems to gnome 2.18, and all other stable
upgrades. However, now it seems like linking pulls in every fsking lib on
the system, whether needed or not? In particular, this becomes a big
problem because one of the libs that gets pulled in libGL.so.1, doesn't
exist as a PIC executable, and this means that prelink breaks, hardened
breaks (plus the overhead of having to pull in bunches of libraries that
aren't used at all).

Do anyone know of a way to get the old functionality back, where only the
libraries that are needed for a package gets linked, instead of linking
against everything and its dog?

Regards,
--
*Art

On Sun, 12 Aug 2007 16:56:50 -0400, Arthur Hagen <art@broomstick.com> wrote:


>I just completed upgrading three systems to gnome 2.18, and all other stable
>upgrades. However, now it seems like linking pulls in every fsking lib on
>the system, whether needed or not? In particular, this becomes a big
>problem because one of the libs that gets pulled in libGL.so.1, doesn't
>exist as a PIC executable, and this means that prelink breaks, hardened
>breaks (plus the overhead of having to pull in bunches of libraries that
>aren't used at all).

>Do anyone know of a way to get the old functionality back, where only the
>libraries that are needed for a package gets linked, instead of linking
>against everything and its dog?

Useflags control which packages are dependencies. It is up to the individual
packages how they are linked. However, if their ./configure script don't call
for a particular feature, then that feature won't get linked.

Do an 'emerge -pv' on the package in question and make sure you don't have any
useflags calling in unwanted features. Sometimes you have to have a negative
use flag in your make.conf to get rid of something -- the default w/ no
use flag is a positive.

AZ Nomad <aznomad.2@PremoveOBthisOX.COM> wrote:
> On Sun, 12 Aug 2007 16:56:50 -0400, Arthur Hagen <art@broomstick.com>
> wrote:
>
>
>> I just completed upgrading three systems to gnome 2.18, and all
>> other stable upgrades. However, now it seems like linking pulls in
>> every fsking lib on the system, whether needed or not? In
>> particular, this becomes a big problem because one of the libs that
>> gets pulled in libGL.so.1, doesn't exist as a PIC executable, and
>> this means that prelink breaks, hardened breaks (plus the overhead
>> of having to pull in bunches of libraries that aren't used at all).
>
>> Do anyone know of a way to get the old functionality back, where
>> only the libraries that are needed for a package gets linked,
>> instead of linking against everything and its dog?
>
> Useflags control which packages are dependencies. It is up to the
> individual packages how they are linked. However, if their
> ./configure script don't call for a particular feature, then that
> feature won't get linked.
>
> Do an 'emerge -pv' on the package in question and make sure you don't
> have any useflags calling in unwanted features. Sometimes you have
> to have a negative use flag in your make.conf to get rid of something
> -- the default w/ no
> use flag is a positive.

No, this isn't due to use flags (at least not directly), cause linking of
apps that do /not/ use opengl and do not have an opengl use flag either now
links against opengl if a dependent library links to a library which links
to a library which /can/ use OpenGL. Deep linking, in other words, which is
a horrible thing.
This is new, and breaks a lot of things, most notably prelink and remote X
where the remote X server doesn't support OpenGL. It may be a problem with
other libraries too -- I can imagine any other extension to X would cause a
problem.

Regards,
--
*Art

Arthur Hagen <art@broomstick.com> wrote:
>>
>>> Do anyone know of a way to get the old functionality back, where
>>> only the libraries that are needed for a package gets linked,
>>> instead of linking against everything and its dog?

Add -Wl,--as-needed to your LDFLAGS in /etc/make.conf
(I was previously thinking that this flag should not be needed for
properly written software, but unfortunately many libraries are not
properly written).

> No, this isn't due to use flags (at least not directly), cause linking of
> apps that do /not/ use opengl and do not have an opengl use flag either now
> links against opengl if a dependent library links to a library which links
> to a library which /can/ use OpenGL. Deep linking, in other words, which
> is a horrible thing.

AFAIK, this is a design flaw of some libraries, essentially due to these
horrible autotools: the configuration of these libraries simply
always return a huge list of -l...-Flags, no matter whether a
feature of that other library might be needed or not.
It appears tha the "-Wl,-as-needed" LDFLAG is no the "official"
solution of Gentoo for these design flaws (although, of course,
this flag is dangerous and might break other things).

On Thu, 2007-08-16 at 11:43 +0000, Martin Vaeth wrote:
> Arthur Hagen <art@broomstick.com> wrote:
> >
> > Unfortunately, adding "-Wl,--as-needed" to LDFLAGS and rebuilding world
> > twice didn't help much.
> > A main problem seems to be that cairo now can build against opengl,
> > which in turn affects all binaries that use cairo /whether they
> > themselves use opengl or not/.
>
> If it is as you say, then the problem is not gcc/autotools but
> cairo itself: Probably the way cairo is built on your system,
> one function of cairo which is used by most binaries in turn uses
> a function of opengl. It USES it, and so there is no chance that
> your binary can run without opengl. (Otherwise, the dependency
> would have been dropped by -Wl,--as-needed).

That is not 100% accurate, unfortunately - the library might STILL be
needed.
Let me clarify with an example:

/* foo.c */
#include <stdio.h>
#include "cairo/cairo.h"
int main(void){
puts(cairo_version_string());
return 0;
}

gcc -o foo foo.c -I/usr/include/cairo -Wl,--as-needed -lcairo

(Never mind that the -I/usr/include/cairo shouldn't be needed, if
includes had used <cairo/xxx.h> and "xxx.h" correctly, instead of
<xxx.h>)

This program only calls a function that returns a string, and cairo
doesn't use opengl for this.

However, if you compile this on a system where cairo has been compiled
with the "opengl" use flag, libGL will still be required (and loaded
when you run foo):

# ./foo
1.4.10
# cd `ldd foo |awk '($1 == "libGL.so.1") {print "dirname "$3}' | sh`
# mv libGL.so.1 libGL.so.1.bak
# cd -
# ./foo
../foo: error while loading shared libraries: libGL.so.1: cannot open
shared object file: No such file or directory

The error is because with the GNU linker, cairo /requires/ libGL.so.1 to
be loaded at run time, even though the function you call doesn't use it.

# cd -
# mv libGL.so.1.bak libGL.so.1

What I'm used to from other systems is that the dynamic linker doesn't
dlopen() all libraries at load time, but only when (and if) first used.
The GNU dynamic linker doesn't appear to support this, but requires all
libraries to be present and opened at run time.

With the GNU approach, you also can't share out /usr/lib between
systems, without also sharing out every lib that a lib in /usr/lib is
linked against, no matter where they're located. This breaks typical
old-school NFS mounted directories.

Regards,
--
*Art

Arthur Hagen <art@broomstick.com> wrote:
>
> The error is because with the GNU linker, cairo /requires/ libGL.so.1 to
> be loaded at run time, even though the function you call doesn't use it.

You are right. I would not have expected this from the description
of --as-needed. This makes --as-needed a rather poor option (although
it is still better than without --as-needed).

Arthur Hagen <art@broomstick.com> wrote:
> On Thu, 2007-08-16 at 11:43 +0000, Martin Vaeth wrote:
>> -Wl,--relax and -Wl,-z,now.
>> In particlar, I recommend the latter for security reasons. (Unfortunately,
>> xorg itself has problems with this option).
>
> I strongly recommend *against* ever using "-Wl,-z,now", because it
> causes libraries that might not even be used to be loaded, increasing
> both startup time and memory usage.

Concerning memory usage, I found no dramatic difference on my system, but
actually startup time of large programs like kde has even slighly
decreased with -Wl,-z,now.
This might be by accident (better placement of libraries on the harddisk)
but perhaps the "later" resolving of symbols has some more overhead
(I suspect that lazy linking might even increase the runtime if a library
function is often called, because the linker has to check first that
it is there? However, I have not analyzed the code or made experiments
whether this is correct.)
Nevertheless, these are minor points IMHO.
I am more concerened about the security issue:
To be honest, I did not understand the reason precisely, but roughly,
I think that the problem is that the code pages are associated
to owners and that you might somehow be able to modify the
library of a lazy-linked program of a different owner.
Perhaps this problem happens only for SUID or GUID programs.
But firstly, there are a lot of such programs on a system, and
secondly, these programs in turn use libraries (I am not sure what
happens if a -Wl,-z,now linked binary uses a library which is linked
without this flag). So I think that with -Wl,-z,now you are usually
on the safer side.

> IMO, the better solution to avoid
> library impersonation is to use -rpath when linking.

I do not understand how this solves the above security issue.
Moreover, if it does, how can you be sure that all packages on your system
use -rpath in the correct manner? (It is practically impossible to
check manually all installation scripts of all installed packages).

On Fri, 2007-08-17 at 14:20 +0000, Martin Vaeth wrote:
> Arthur Hagen <art@broomstick.com> wrote:

> I am more concerened about the security issue:
> To be honest, I did not understand the reason precisely, but roughly,
> I think that the problem is that the code pages are associated
> to owners and that you might somehow be able to modify the
> library of a lazy-linked program of a different owner.
> Perhaps this problem happens only for SUID or GUID programs.
> But firstly, there are a lot of such programs on a system, and
> secondly, these programs in turn use libraries (I am not sure what
> happens if a -Wl,-z,now linked binary uses a library which is linked
> without this flag). So I think that with -Wl,-z,now you are usually
> on the safer side.
>
> > IMO, the better solution to avoid
> > library impersonation is to use -rpath when linking.
>
> I do not understand how this solves the above security issue.
> Moreover, if it does, how can you be sure that all packages on your system
> use -rpath in the correct manner? (It is practically impossible to
> check manually all installation scripts of all installed packages).

The way I understand it, the security issue is that without either
-Wl,-z,now nor -rpath, the system will, when it's time to call a library
check whether the library is loaded first, and use the loaded copy if
available, and if not, take the first one it finds in LD_LIBRARY_PATH if
set, and if not set or found there, consult the ldconfig database to see
which one to load, and finally try the default path.
With -Wl,-z,now, you force all the libraries to be loaded and
locked[1] immediately using the above approach, meaning someone can't
load a different library with the same name and have that called
instead. The downside is that the libraries will be loaded and mapped
whether needed or not, and it doesn't really add security for the cases
where a compromised library is loaded /before/ you start your app.
With -rpath, not only does the name of the library have to match, but
the path too. So if you use -rpath /usr/local/lib -lfoo,
only /usr/local/lib/libfoo.so will satisfy the criterion, and even if
someone loads ~malicioususer/libfoo.so, it won't be used.
In addition, with -rpath, it overrides LD_LIBRARY_PATH, so even if a
malicious user has managed to set the LD_LIBRARY_PATH to point to
replacement libraries that do bad things, they won't be used.
The major downside to -rpath is that for remotely mounted file
systems, you need to keep the path the same, and can't simply
add /mnt/server/usr/lib to a system's LD_LIBRARY_PATH. Nor can you move
the DSOs around for other reasons (like moving a library from /usr/lib
to /lib if it needs to be found at boot before /usr is mounted).

I can't see how it would be much more work to maintain, because you
already have to keep track of the path you install the libraries to.

For the slight speed increase you saw using KDE, this is easily
explained: Most KDE programs use the same libraries, and by using
Wl,-z,now, you force them to be loaded and locked[1] by the first
program that uses them, and all other apps will then use the copy in
memory. Especially if combined with prelink, this might help when using
an environment where mostly the same libraries are used over and over
again with the same apps. (With prelink, the memory mapping is done
ahead of time, and saved to the binary/library, which increases the file
size but /greatly/ decreases the startup speed, especially when using
the same libraries over and over again by different apps.)

For a non-security aspect, -rpath is mostly used for better "slotting",
in that you can have two packages use the same library name and version
numbers but keep their libraries in different places, so if you upgrade
one of them, it won't affect the others, and the libraries can be
compiled with different options. Like, for example,
mozilla/firefox/seamonkey. An example of a package that could benefit
from -rpath is java, where you frequently have to keep multiple versions
due to incompatibilities, and you quickly end up with a LD_LIBRARY_PATH
nightmare, where every startup script you use has to be modified so the
right libraries will be used (or, commonly, using a java wrapper that
sets it for you, with the overhead that incurs).

Again, I'm not an expert on this, so I could be wrong in some details,
but I have read and experimented a fair bit, on different systems,
following the rule that what /actually/ happens doesn't always match
what people say /should/ happen, and in the cases where the map doesn't
match the terrain, it's safe to assume that the terrain is correct.

[1]: Actually, I believe it's the use count that's increased. This is
cooperative, and not 100% safe. One app can potentially do a specially
written close equivalent and knock down the lock count to zero, causing
the dso to be unloaded, and then inject a substitute. Better locking
exists, including using linked lists, where only the process that opened
a library is allowed to say it's done with it. ICBW, but I believe that
in Linux, the simple counter method is still used, while in SunOS and
Trusted IRIX, the safer and slower approaches are used.

Regards,
--
*Art

Arthur Hagen <art@broomstick.com> wrote:
>
> [great explanation about the security issue without -rpath]

Thank you very much for the explanation. I have now really understood
the problem for the first time. Indeed, I also made some experiments now,
and all experiments said that you are completely right (contradicting
some false informations which I had before).

However, how can one get a full running system where every libraray
is linked with -rpath? Most upstream projects use autotools which
unfortunately do not have a ./configue option to add the appropriate
-rpath everywhere. One might try to hack autotools, but this would
mean to modify many versions of autotools and would probably break
many projects.
Is it possible to patch binaries/libraries to include corresponding
-rpath's *after* they are created with ldd?
In this case, it might be possible to write a tool like prelink
which adds this -rpath's and let it run over your whole system
(or even better: Patch portage to run this tool after the install
phase so that also new emerges are correct and that you do not
get troubles with wrong checksums when uninstalling something.
It might even be a portage FEATURE then so that it might be
deactivated on user request or for certain packages for which you
want e.g. to care about LD_LIBRARY_PATH for some reason).

> I can't see how it would be much more work to maintain, because you
> already have to keep track of the path you install the libraries to.

If you are writing a new project without autotools, this is
certainly easy to manage. However, my problem is how to apply -rpath
to hundreds of existing projects "automatically" (i.e. without manually
modifying the build system of each single project).

Martin Vaeth wrote:
> clifto <clifto@gmail.com> wrote:
>> AZ Nomad wrote:
>>> Do an 'emerge -pv' on the package in question and make sure you don't have any
>>> useflags calling in unwanted features. Sometimes you have to have a negative
>>> use flag in your make.conf to get rid of something -- the default w/ no
>>> use flag is a positive.
>>
>> ...which makes it a pity that ufed won't create a negative use flag, but
>> leaves gullible fools like me believing that shutting off a use flag in
>> ufed means the use flag is off.
>
> Why do you think that ufed does not create negative use flags?

Because I went looking for one the other day. (I'm not having any luck
retracing my steps in order to name it.) It was not mentioned in the USE
string in /etc/make.conf, which I would take as a negative, but the code
that was compiling was treating it as if something had it set positively;
ufed showed it as unselected, and I couldn't find any way to make ufed
put a -useflag into the USE string. I had to manually change make.conf
to shut it down.

--
"You know the difference between cannibals and liberals?
Cannibals only eat their enemies."
-- Lyndon Baines Johnson