Summary: SELinux is preventing /usr/bin/gdb "write" access on /usr/share/glib-2.0/gdb. Detailed Description: SELinux denied access requested by gdb. It is not expected that this access is required by gdb and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:NetworkManager_t:s0 Target Context system_u:object_r:usr_t:s0 Target Objects /usr/share/glib-2.0/gdb [ dir ] Source gdb Source Path /usr/bin/gdb Port <Unknown> Host (removed) Source RPM Packages gdb-6.8.91.20090930-2.fc12 Target RPM Packages glib2-devel-2.22.2-1.fc12 Policy RPM selinux-policy-3.6.32-22.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.1-56.fc12.x86_64 #1 SMP Tue Sep 29 16:16:22 EDT 2009 x86_64 x86_64 Alert Count 2 First Seen Sat 10 Oct 2009 02:49:09 PM EDT Last Seen Sat 10 Oct 2009 02:49:09 PM EDT Local ID aaa85630-c821-46d5-bda7-dceecab64191 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1255200549.104:26514): avc: denied { write } for pid=11666 comm="gdb" name="gdb" dev=sdc7 ino=77919 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1255200549.104:26514): arch=c000003e syscall=2 success=no exit=-13 a0=7fff851ddf10 a1=2c1 a2=81ed a3=1 items=0 ppid=11665 pid=11666 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gdb" exe="/usr/bin/gdb" subj=system_u:system_r:NetworkManager_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-22.fc12,catchall,gdb,NetworkManager_t,usr_t,dir,write audit2allow suggests: #============= NetworkManager_t ============== allow NetworkManager_t usr_t:dir write;
/usr/share/glib-2.0/gdb/glib.pyc is not owned by this package, causing any app that uses gdb to create this file which generates this AVC.
If I own that file, I get a multilib conflict that I don't want...
Well I can not give random apps the ability to write to /usr.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 530610 has been marked as a duplicate of this bug. ***
We don't actually need write permissions, it will just fail the write and go merrily on. Maybe we can have gdb set sys.dont_write_bytecode attribute to avoid these problems: http://docs.python.org/3.1/library/sys.html#sys.dont_write_bytecode
*** Bug 545378 has been marked as a duplicate of this bug. ***
*** Bug 543156 has been marked as a duplicate of this bug. ***
sys.dont_write_bytecode is a global setting, not per-directory/per-file. If it should be set by gdb then it should be set by python - which is wrong. The problem is I do not have it reproducible. And this problem is out of scope of GDB, reassigning to python.
My guess is that you have to be running gdb as root to see this, otherwise the DAC would have failed before SELinux does the MAC check. Looks to me like a packaging bug in glib2-devel (as per comment #1): $ rpm -qf /usr/share/glib-2.0/gdb/glib.py glib2-devel-2.22.2-2.fc12.i686 $ ls /usr/share/glib-2.0/gdb/glib.pyc ls: cannot access /usr/share/glib-2.0/gdb/glib.pyc: No such file or directory As I understand it, gdb is embedding Python; if the .pyc file isn't present it will have to reparse the .py file every time. sys.dont_write_bytecode is a global setting within the currently running python process. You can set it from C code via the Py_DontWriteBytecodeFlag boolean. One other way to solve this is to set this when starting up libpython from inside gdb. That way /usr/bin/gdb wouldn't try writing this bytecode, but /usr/bin/python would. Reassigning to glib2. Re comment #2, the pyc file ought to be arch-independent. It embeds the mtime of the .py file; can you ensure that these are constant by unpacking the .py file with timestamp-preservation during the build?
*** Bug 549485 has been marked as a duplicate of this bug. ***
*** Bug 550341 has been marked as a duplicate of this bug. ***
*** Bug 538300 has been marked as a duplicate of this bug. ***
*** Bug 541739 has been marked as a duplicate of this bug. ***
The .pyc files where removed since they caused multilib conflicts as explained in bug 525213. Maybe this could be fixed in some other way to make the .pyc files identical. But, even if this is possible to fix that way I don't think that gdb should be writing .pyc files to system directories if run as root. .py files found by gdb may be installed from other sources and not have corresponding .pyc files which would cause this error to pop up again.
(In reply to comment #15) > The .pyc files where removed since they caused multilib conflicts as explained > in bug 525213. /usr/share/gdb/auto-load/lib64/libglib-2.0.so.0.2200.3-gdb.py /usr/share/gdb/auto-load/lib64/libglib-2.0.so.0.2200.3-gdb.pyc /usr/share/gdb/auto-load/lib64/libglib-2.0.so.0.2200.3-gdb.pyo /usr/share/gdb/auto-load/lib64/libgobject-2.0.so.0.2200.3-gdb.py /usr/share/gdb/auto-load/lib64/libgobject-2.0.so.0.2200.3-gdb.pyc /usr/share/gdb/auto-load/lib64/libgobject-2.0.so.0.2200.3-gdb.pyo /usr/share/glib-2.0 /usr/share/glib-2.0/gdb /usr/share/glib-2.0/gdb/glib.py /usr/share/glib-2.0/gdb/gobject.py OK, so glib.py and gobject.py should not be in /usr/share/glib-2.0 but in /usr/%{_lib}/glib-2.0. GDB loads only those from /usr/share/gdb/auto-load so it is fully on glib2 packaging where it places the real glib.py* and gobject.py* files. Another problem is the source files (.py) duplicity in multilib but this is a problem of upstream Python and glib2 should not try to solve it on its own: *.py files should be in /usr/share/ (or always just in /usr/lib/) and *.py{c,o} files in /usr/lib{,64}/ . This would require support for different directory for source file vs. destination object file. But this is currently not supported by upstream Python API: http://docs.python.org/library/compileall.html I do not know much about Python, this is just what I have found.
*** Bug 558385 has been marked as a duplicate of this bug. ***
*** Bug 559060 has been marked as a duplicate of this bug. ***
*** Bug 560882 has been marked as a duplicate of this bug. ***
*** Bug 562183 has been marked as a duplicate of this bug. ***
*** Bug 565279 has been marked as a duplicate of this bug. ***
*** Bug 565276 has been marked as a duplicate of this bug. ***
Shouldn't these -gdb.py files be shipped within the debuginfo packages? I figured out a way to do this for the python rpms themselves (which recently grew gdb 7 hooks), byte-compiling the files, then installing them into e.g.: /usr/lib/debug/%{_libdir}/libpython26.so.1.0-gdb.py* See: http://lists.fedoraproject.org/pipermail/packaging/2010-February/006868.html http://cvs.fedoraproject.org/viewvc/rpms/python3/devel/python3.spec?r1=1.11&r2=1.12 and parts of this change: http://cvs.fedoraproject.org/viewvc/rpms/python/devel/python.spec?r1=1.168&r2=1.169
I don't see why you would need the debuginfo package to get the debug helpers, it seems more useful in the -devel package.
Alex: as I understand it, your glib gdb.py helpers contain pretty-printers and backtrace renderers. I think there are three use cases for library-specific gdb extensions like this: (a) to make backtraces supplied by ABRT contain useful library-specific information (e.g. the actual GObject subclass rather than "(GObject*)", the repr of a PyObject* rather than just the hexadecimal addresses, etc), so that an entirely non-technical user is able to automatically supply high-value bug reports. (b) to make it easier to talk a semi-technical user through the process of getting details about a crasher that the developer isn't yet able to reproduce (c) to provide extra power for developers investigating a problem with the library One of the motivating features for my gdb.py work on Python itself was for use case (a) As I understand it, ABRT is designed to load the -debuginfo subpackage, but no -devel subpackages. Also, I believe that the pretty-printers can't work without the DWARF data, and that's in the -debuginfo subpackage. Hence, assuming I've got the above correct, it would help with ABRT GNOME bug reports if the .py files were in the debuginfo subpackage: you need that package anyway for it to work for use case (c), and all crashers in any GTK app reported via ABRT would automatically leverage your work, without needing non-expert involvement.
dave: Thats true, seems better to move it to debuginfo then.
*** Bug 578679 has been marked as a duplicate of this bug. ***
*** Bug 546380 has been marked as a duplicate of this bug. ***
*** Bug 601964 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
*** Bug 665543 has been marked as a duplicate of this bug. ***
Created attachment 471030 [details] glib2-2.26.0-2.fc14 .spec fix.
*** Bug 680908 has been marked as a duplicate of this bug. ***
*** Bug 691068 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping