Bug 715203

+++ This bug was initially created as a clone of Bug 528554 +++


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;

--- Additional comment from dwalsh onTue Oct 13 14:13:15 EDT 2009 ---
/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.

--- Additional comment from mclasen onTue Oct 13 14:36:19 EDT 2009 ---
If I own that file, I get a multilib conflict that I don't want...

--- Additional comment from dwalsh onTue Oct 13 15:30:45 EDT 2009 ---
Well I can not give random apps the ability to write to /usr.

--- Additional comment from triage.org onMon Nov 16 13:34:04 EST 2009 ---

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

--- Additional comment from mclasen onMon Nov 23 22:02:08 EST 2009 ---
*** Bug 530610 has been marked as a duplicate of this bug. ***

--- Additional comment from alexl onWed Nov 25 14:04:21 EST 2009 ---
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

--- Additional comment from dwalsh onWed Dec 09 13:40:27 EST 2009 ---
*** Bug 545378 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onWed Dec 09 13:40:49 EST 2009 ---
*** Bug 543156 has been marked as a duplicate of this bug. ***

--- Additional comment from jan.kratochvil onWed Dec 09 17:40:08 EST 2009 ---
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.

--- Additional comment from dmalcolm onThu Dec 10 20:35:43 EST 2009 ---
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?

--- Additional comment from dwalsh onMon Dec 21 19:49:22 EST 2009 ---
*** Bug 549485 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onSun Dec 27 13:01:47 EST 2009 ---
*** Bug 550341 has been marked as a duplicate of this bug. ***

--- Additional comment from mclasen onMon Jan 04 18:03:49 EST 2010 ---
*** Bug 538300 has been marked as a duplicate of this bug. ***

--- Additional comment from jan.kratochvil onTue Jan 05 21:15:36 EST 2010 ---
*** Bug 541739 has been marked as a duplicate of this bug. ***

--- Additional comment from alexl onMon Jan 11 11:42:35 EST 2010 ---
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.

--- Additional comment from jan.kratochvil onMon Jan 11 14:05:36 EST 2010 ---
(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.

--- Additional comment from dwalsh onMon Jan 25 17:58:54 EST 2010 ---
*** Bug 558385 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onWed Jan 27 16:01:51 EST 2010 ---
*** Bug 559060 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl onTue Feb 02 12:08:18 EST 2010 ---
*** Bug 560882 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onFri Feb 05 16:06:42 EST 2010 ---
*** Bug 562183 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onSun Feb 14 14:22:50 EST 2010 ---
*** Bug 565279 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onSun Feb 14 14:40:18 EST 2010 ---
*** Bug 565276 has been marked as a duplicate of this bug. ***

--- Additional comment from dmalcolm onMon Feb 15 20:10:28 EST 2010 ---
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

--- Additional comment from alexl onWed Feb 24 09:53:38 EST 2010 ---
I don't see why you would need the debuginfo package to get the debug helpers, it seems more useful in the -devel package.

--- Additional comment from dmalcolm onWed Feb 24 17:18:05 EST 2010 ---
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.

--- Additional comment from alexl onThu Feb 25 10:25:11 EST 2010 ---
dave: Thats true, seems better to move it to debuginfo then.

--- Additional comment from dwalsh onThu Apr 01 12:44:48 EDT 2010 ---
*** Bug 578679 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh onMon Apr 05 12:51:41 EDT 2010 ---
*** Bug 546380 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl onWed Jun 09 11:50:16 EDT 2010 ---
*** Bug 601964 has been marked as a duplicate of this bug. ***

--- Additional comment from triage.org onThu Nov 04 09:29:46 EDT 2010 ---

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

--- Additional comment from triage.org onSat Dec 04 07:29:45 EST 2010 ---

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.

--- Additional comment from jan.kratochvil onWed Dec 29 02:22:49 EST 2010 ---
*** Bug 665543 has been marked as a duplicate of this bug. ***

--- Additional comment from jan.kratochvil onWed Dec 29 04:43:30 EST 2010 ---
Created attachment 471030 [details]
glib2-2.26.0-2.fc14 .spec fix.

--- Additional comment from dwalsh onMon Feb 28 18:15:33 EST 2011 ---
*** Bug 680908 has been marked as a duplicate of this bug. ***

--- Additional comment from jan.kratochvil onMon Mar 28 11:22:40 EDT 2011 ---
*** Bug 691068 has been marked as a duplicate of this bug. ***