Bug 440592
Summary: | AVC denial when going online | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Schmidt <mschmidt> | ||||
Component: | jabbim | Assignee: | Michal Schmidt <mschmidt> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | ||||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-04-04 11:31:24 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Michal Schmidt
2008-04-04 09:14:23 UTC
I tried using strace to find a syscall failing with EACCES, but didn't find anything relevant. So I used systemtap to find where exactly in the kernel the AVC denial is happening and got this backtrace: 0xffffffff8106d0e9 : audit_log_start+0x1/0x396 0xffffffff8111092c : avc_audit+0x79/0x9c8 0xffffffff819b7dc0 : packet_exit+0x498c0a/0x7e0e0e4a 0xffffffff81110885 : avc_has_perm_noaudit+0x45d/0x48b 0xffffffff819be138 : packet_exit+0x49ef82/0x7e0e0e4a 0xffffffff811112c9 : avc_has_perm+0x4e/0x60 0xffffffff81112ed6 : inode_has_perm+0x5b/0x61 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff81112ffd : file_has_perm+0x84/0x8f 0xffffffff81051b6d : lock_release_holdtime+0x1e/0x108 # flush_unauthorized_files is inlined here 0xffffffff81117159 : selinux_bprm_post_apply_creds+0x1c5/0x424 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff8110d963 : security_bprm_post_apply_creds+0xe/0x10 0xffffffff810b1c58 : compute_creds+0xc9/0xce 0xffffffff810e2639 : load_elf_binary+0xe99/0x1730 0xffffffff810120aa : sched_clock+0x50/0x6d 0xffffffff813ece58 : __stop_notes+0x13c5c4/0x22176c 0xffffffff813ece40 : __stop_notes+0x13c5ac/0x22176c 0xffffffff810e17a0 : load_elf_binary+0x0/0x1730 0xffffffff813f23c0 : __stop_notes+0x141b2c/0x22176c 0xffffffff810e17a0 : load_elf_binary+0x0/0x1730 0xffffffff810b1a0c : search_binary_handler+0xca/0x24d 0xffffffff810b2d3d : do_execve+0x1b8/0x24e 0xffffffff8100a62c : sys_execve+0x3e/0x59 0xffffffff8100c48a : stub_execve+0x6a/0xc0 This tells me Jabbim (or Python itself) execs ldconfig, but it leaves a fd open for reading for autoaway.py (and archive.py, I'm seeing a second denial for that one). Created attachment 300408 [details]
close the plugin source file's fd before instantiating the plugin
I have it. Jabbim leaves the plugin's source file open after doing load_source
on it. Then it creates an instance of the plugin which then runs ldconfig -p.
The fix is to close the file before calling the plugin's constructor.
Upstream applied the patch in SVN revision 2563. |