Description of problem: SELinux is preventing /usr/bin/gdb from using the 'ptrace' accesses on a process. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that gdb should be allowed ptrace access on processes labeled svirt_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep gdb /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:svirt_t:s0:c37,c769 Target Context system_u:system_r:svirt_t:s0:c37,c769 Target Objects [ process ] Source gdb Source Path /usr/bin/gdb Port <Unknown> Host (removed) Source RPM Packages gdb-7.5.1-30.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-59.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.6.7-5.fc18.x86_64 #1 SMP Tue Nov 20 19:40:08 UTC 2012 x86_64 x86_64 Alert Count 1 First Seen 2012-12-04 16:10:08 EST Last Seen 2012-12-04 16:10:08 EST Local ID ea1fa15d-83a3-436b-8d9b-cc47dcad9e6d Raw Audit Messages type=AVC msg=audit(1354655408.104:558): avc: denied { ptrace } for pid=11865 comm="gdb" scontext=system_u:system_r:svirt_t:s0:c37,c769 tcontext=system_u:system_r:svirt_t:s0:c37,c769 tclass=process type=SYSCALL msg=audit(1354655408.104:558): arch=x86_64 syscall=ptrace success=no exit=EACCES a0=10 a1=2deb a2=0 a3=0 items=0 ppid=11861 pid=11865 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=gdb exe=/usr/bin/gdb subj=system_u:system_r:svirt_t:s0:c37,c769 key=(null) Hash: gdb,svirt_t,svirt_t,process,ptrace audit2allow audit2allow -R Additional info: hashmarkername: setroubleshoot kernel: 3.6.7-5.fc18.x86_64 type: libreport
Why would an svirt instance be running gdb?
I run gnome boxes and while starting the guest installation, it evokes this error and the installation fails.
Rahul, I would run in permissive mode and see what is blowing up. Something is blowing up and SELinux is blocking the qemu process from attempting to debug the problem.
*** Bug 963954 has been marked as a duplicate of this bug. ***
Description of problem: Shutdown VM. Parallely connected in virsh to qemu:///system Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.3-301.fc19.x86_64 type: libreport
Description of problem: vm in gnome boxes crashed. Additional info: reporter: libreport-2.1.6 hashmarkername: setroubleshoot kernel: 3.10.11-200.fc19.x86_64 type: libreport
Description of problem: virsh shutdown desktop.example.com Additional info: reporter: libreport-2.1.8 hashmarkername: setroubleshoot kernel: 3.11.4-201.fc19.x86_64 type: libreport
Could this be caused by abrt?
Yes, this is probably caused by abrt trying to report a QEMU crash. Unfortunately, there's not much that we can do in QEMU with such a generic report and no backtrace. What is the fix? Should abrt run gdb with a special context that is allowed to ptrace any process, or something like that?
abrt runs gdb only on a coredump file which is placed in /var/tmp/abrt and runs it under the abrt user. abrt never attaches a running process. One would expect that this is not an issues, since it works fine for all other binaries|components.
*** Bug 1060551 has been marked as a duplicate of this bug. ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days