Hi, (first: sorry my very bad english) I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step. Then when executed, the ld-linux will find libraries first in the rpath , and if fails will go to search in the cache ld.so.cache, instead of directly search here) So for example if you execute the... setfacl/getfacl/chacl (in package from core/acl, and this is the only package in [core] that have this issue with binaries) will find in libs in varius incorrects paths for example: $ readelf -d /usr/bin/getfacl | grep RPATH 0x0000000f (RPATH) Library rpath: [/home/thomas/arch/repos/core/base/acl/pkg/usr/lib] $ LD_DEBUG=libs setfacl 10323: find library=libacl.so.1 [0]; searching 10323: search (*** stripped here same paths below... ***) (RPATH from file setfacl) 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/libacl.so.1 10323: search cache=/etc/ld.so.cache 10323: trying file=/lib/libacl.so.1 10323: The issue here is for example if a user "thomas" in my system, create a libacl.so.1 in any of these paths, the setfacl will use them insteads of the correct libacl.so.1, and if the libacl.so.1 from thomas contain a malicious code, the user that execute it are in problem :(, root for example. OK managing rpath at build time vary from package to package, some that uses autotools/libtool, the configure script, have a --disable-rpath for controling this behavior, and other don't have. Others require rpath at build time to linking executables from the same source, and other always hardcore it (gcc -Wl,--rpath...), etc, etc. In libtool, can change a M4 macro to don't use rpath for example. There is a simple tool, to remove rpath from ELF files called chrpath [#1] (seems that cmake build system can use an aproach based on chrpath to delete rpath from ELF) For example: # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2008-02-26 13:23 /usr/bin/setfacl # chrpath -d /usr/bin/setfacl # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2009-03-20 01:06 /usr/bin/setfacl # LD_DEBUG=libs setfacl 11033: find library=libacl.so.1 [0]; searching 11033: search cache=/etc/ld.so.cache 11033: trying file=/lib/libacl.so.1 And now is correct and secure. The minor problem here, _and don't make much sense_ is that will do some aditionals system calls open() and stat64() for each inexistent libs on loading. Many others have /usr/lib (and many many others paths) as rpath, then when execute will look for the first library that need to load at /usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2 (and these are removed from search path for next libs), and then for all libs will look first in /usr/lib if fails do a /etc/ld.so.cache search The rpath is important when managing many versions of the same libs with same soname, for example for debuging/testing purposes. For example i see googling that in some distros (like Debian[s]) and in some BSDs the rpath is removed from all ELF files, except that in that is necessary required. Then my question: what is the position of arch-dev-team about rpath? (remember: don't take this as a mail as feature request, is just one question) Thanks in advance, I hope not to have bothered with this. Good Luck! / ¡Buena suerte! [#1] chrpath: The original home don't work http://directory.fsf.org/project/chrpath/ i use a debian mirror in my pkgbuild http://aur.archlinux.org/packages.php?ID=24818 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D