FS#13891 - [acl] A trivial fix RPATH issue
Attached to Project:
Arch Linux
Opened by Gerardo Exequiel Pozzi (djgera) - Friday, 20 March 2009, 23:30 GMT
Last edited by Allan McRae (Allan) - Saturday, 21 March 2009, 00:17 GMT
Opened by Gerardo Exequiel Pozzi (djgera) - Friday, 20 March 2009, 23:30 GMT
Last edited by Allan McRae (Allan) - Saturday, 21 March 2009, 00:17 GMT
|
Details
Description: setfacl, getfacl and chacl from acl-2.4.27-1
have a hardcoded rpath in the binaries pointing to
/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/
Then if a libacl.so.1 are in this dir, is used, and if contains a malicious code, the user that execute any of these programs are in problem. A trivial fix is attached, patching a file to add $DESTDIR to the build and then the executables are created without rpath. Steps to reproduce: $ pwd /home/thomas/arch/repos/core/base/acl/pkg/usr/lib $ cat saludo.c #include <stdio.h> void saludo() { printf("HOLA AQUI ESTOY\n"); } $ cat symver ACL_1.0 { saludo; }; $ gcc -c -fPIC -o saludo.o saludo.c $ gcc -shared -Wl,--version-script,symver -Wl,-soname,libacl.so.1.0 -Wl,-init,saludo -o libacl.so.1 saludo.o [root@gerardo ~]# pwd /root [root@gerardo ~]# setfacl --version HOLA AQUI ESTOY setfacl 2.2.47 [root@gerardo ~]# More detailed info about rpath issue in this report: |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 21 March 2009, 00:17 GMT
Reason for closing: Fixed
Additional comments about closing: in [testing]
Saturday, 21 March 2009, 00:17 GMT
Reason for closing: Fixed
Additional comments about closing: in [testing]
Comment by Allan McRae (Allan) -
Saturday, 21 March 2009, 00:17 GMT
acl-2.4.27-2 which has this fix is now in [testing]