Description of problem: I tried to use storuss $ sotruss ls ERROR: ld.so: object '/usr/$LIB/audit/sotruss-lib.so' cannot be loaded as audit interface: cannot open shared object file; ignored. zsh: segmentation fault (core dumped) sotruss ls I guess the path is wrong Version-Release number of selected component: coreutils-8.17-7.fc18 Additional info: backtrace_rating: 3 cmdline: ls crash_function: __ctype_init executable: /usr/bin/ls kernel: 3.6.11-3.fc18.x86_64 remote_result: NOTFOUND uid: 500 Truncated backtrace: Thread no. 1 (7 frames) #0 __ctype_init at ctype-info.c:32 #1 _init at ../sysdeps/unix/sysv/linux/init-first.c:97 #2 call_init at dl-init.c:67 #4 _dl_init at dl-init.c:131 #5 _dl_start_user at /lib64/ld-linux-x86-64.so.2 #6 ?? #7 ??
Created attachment 676912 [details] File: backtrace
Created attachment 676913 [details] File: cgroup
Created attachment 676914 [details] File: core_backtrace
Created attachment 676915 [details] File: dso_list
Created attachment 676916 [details] File: environ
Created attachment 676917 [details] File: limits
Created attachment 676918 [details] File: maps
Created attachment 676919 [details] File: open_fds
Created attachment 676920 [details] File: proc_pid_status
Created attachment 676921 [details] File: smolt_data
Created attachment 676922 [details] File: var_log_messages
Reassigning to glibc-common, as I suspect it to be caused by sotruss
Structurally I don't see any reasonable way to fix this. security_init () has to be called prior to dlmopen_doit or else things like the constructors of the audit libraries will use different values than later calls would which will cause failures. init_tls () has to be called prior to security_init as the stack guard is kept in the TLS area. There's still an upstream report (referenced by this BZ) so the issue is being tracked upstream.
My point was more ERROR: ld.so: object '/usr/$LIB/audit/sotruss-lib.so' cannot be loaded as audit interface: cannot open shared object file; ignored. ie, $LIB is hardcoded in the path : $ grep \$LIB /usr/bin/sotruss lib='/usr/$LIB/audit/sotruss-lib.so' sotruss just set $LIB_AUDIT. and run the binary. So $LIB_AUDIT will never correctly set. if I set $LIB_AUDIT by hand to the correct value, ( and change the permission on the directory, another issue found after looking on 894307 ), then it work. Should I open another bug report for that, or can I reopen this one ?
I'll reopen this one and twiddle the subject line to track the mucked up $LIB issue.
$LIB is generally expanded to lib or lib64, e.g. dlopen ("/usr/$LIB/libm.so.6", RTLD_LAZY); will open /usr/lib64/libm.so.6 for x86_64 64-bit binary and /usr/lib/libm.so.6 for i686 32-bit binary. LD_PRELOAD='/usr/$LIB/libm.so.6' whatever works too. But I admit I haven't looked what exactly is being that $LIB passed to and why it doesn't handle it.
Indeed, it work, as root : LD_AUDIT='/usr/$LIB/audit/sotruss-lib.so' ls It seems audit package put the directory as 750, and I traced back the change to a commit in the package in in 2006 : commit cb9ea2d589b8fc2e9a8b5f03e8c8a24e87593504 Author: Steve Grubb <sgrubb> Date: Thu Jul 13 20:38:11 2006 +0000 - Switch out dispatcher - Fix bug upgrading rule types I do not understand the rational for the permission change. Steve, any hint ?
Researching this...it sounds like a change was made for something a long time ago and then reverted and this directory is no longer used by the audit package. I can probably delete it so another package can take it over.
OK, got it. At one point during the dispatcher's development, a python version of it shipped in the audit-1.2.5 package. Its python libraries were installed in that directory. As of the audit-1.5 release in March 2007 the dispatcher was rewritten in C and should not have needed that directory any more. I will remove that directory from the spec file and push a new rawhide build through. Sorry...
I built audit-2.2.2-3 in rawhide and f18. I also build audit-2.2.2-2 on f17. These all do not create/own /usr/lib64/audit. They can be downloaded from Koji. I will push the f18/17 ones out after f18 GA. I already have an update queued for 0day and do not want to lose that.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is fixed in f19. I also have developer confirmation that this works in f18 as of today. Therefore making fixed in current release.