I just checked the changelog and found this:
So rpath pointing to the build directory may be a security problem?

I did a readelf on some directories (/usr/bin and /usr/lib64) and found this:
It looks like that some files of the libiodbc package also include the rpath data.

Is this the same problem as for llvm?

I did a small google search and found that ARCH Linux is removing the rpath data from libiodbc by using this command:
chrpath is not part of Slackware but at least some other distros are removing the rpath data from libiodbc.

Some more files with an rpath:
I don't know much about this rpath thing, maybe some one can explain this to me.

EDIT: Tested on Slackware 14.0

Yes, that build of libiodbc is exhibiting the same insecurity as the previous build of llvm.

ELF binaries optionally include a character string that names the directory from which libraries will be loaded. This is colloquially known as the rpath, although there are really two such ELF fields, see https://wiki.debian.org/RpathIssue (which explains about how this relates to other mechanisms such as LD_LIBRARY_PATH).

Normally libtool, cmake etc will set this to an empty string during the build process. Subsequently, the 'chrpath' command can set this to anything, so long as it fits in the original character string field, which is an ugly hack really. Not all upstream packages are as careful about this as they should be, and some of them think rpaths are useful for the upstream devs, and getting rid of them is the packager's responsibility

The problem is that any process which can create directories and files in /tmp (i.e., any process ) could potentially drop a library into (for example) /tmp/ImageMagick-6.7.7-10/magick/.libs which would do something bad (instead of the intended actions) when something else invokes an ImageMagick command. If 'something else' is a root process, 'something bad' would be done as root, which is as bad as it gets.

As an old Multics user, my opinion is that having so many mechanisms for finding libraries, especially having hardcoded paths in executables, is a recipe for confusion and disaster, but the rarity of actual real world disasters shows that I'm only right about the confusion thing

1 members found this post helpful.

Thank you for the explanation.

I did some more research on this issue and found this page from the fedora-project. At the end of the page there are some methods mentioned for how to fix this on packages.

I tried those two sed-lines and they seem to fix rpath on the libiodbc package.

For imagemagick i used this patch from ArchLinux.

For PyQt4 i used a similar sed-command from the Gentoo-Team.

The libplist package could be fixed by adding -DCMAKE_SKIP_RPATH:BOOL=True to the cmake command.

I have to do a fresh install of Slackware 14.1 and check if these (and maybe other) packages are still affected by that.

I'm not sure if it is worth all the effort. If some one has write-access to my system, then something else went wrong.