abrt version: 2.0.1 executable: /usr/bin/abrt-action-install-debuginfo.py cmdline: /usr/bin/python -u /usr/bin/abrt-action-install-debuginfo.py component: abrt package: abrt-addon-ccpp-2.0.1-2.fc15 architecture: x86_64 kernel: 2.6.38.2-9.fc15.x86_64 reason: auto-update-debuginfo.py:86:_write_cached:IOError: [Errno 13] Permission denied: '/var/lib/yum/plugins/auto-update-debuginfo/num.tmp' uid: 173 username: abrt os_release: Fedora release 15 (Lovelock) time: 1303499263 backtrace ----- auto-update-debuginfo.py:86:_write_cached:IOError: [Errno 13] Permission denied: '/var/lib/yum/plugins/auto-update-debuginfo/num.tmp' Traceback (most recent call last): File "/usr/bin/abrt-action-install-debuginfo.py", line 422, in <module> result = downloader.download(missing) File "/usr/bin/abrt-action-install-debuginfo.py", line 200, in download self.repos.doSetup() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 72, in doSetup self.ayum.plugins.run('prereposetup') File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 184, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/auto-update-debuginfo.py", line 111, in prereposetup_hook _write_cached(cfname, rpmdbv, num) File "/usr/lib/yum-plugins/auto-update-debuginfo.py", line 86, in _write_cached fo = open(cfname + ".tmp", "w") IOError: [Errno 13] Permission denied: '/var/lib/yum/plugins/auto-update-debuginfo/num.tmp' Local variables in innermost frame: cdname: '/var/lib/yum/plugins/auto-update-debuginfo' num: 14 cfname: '/var/lib/yum/plugins/auto-update-debuginfo/num' rpmdbv: '1000:48add09a56f1c146b58a608abc4eb8a9205c573b'
Created attachment 494297 [details] File: backtrace
The discussion in Bug 694305 got me wondering if abrt-di could be created if abrt-gui was running as root. It did not create abrt-di and produced this traceback. Procedure: In /var/cache/ [joeblow@fir cache]$ sudo mv -i abrt-di/ abrt-di.BAK [joeblow@fir ~]$ su - Password: [root@fir ~]# sleep 1000 & [1] 2100 [root@fir ~]# kill -6 2100 [root@fir ~]# abrt-gui Cannot connect to Gnome keyring daemon Cannot connect to Gnome keyring daemon Cannot connect to Gnome keyring daemon [1]+ Aborted (core dumped) sleep 1000
Here is the text from the abrt window while running as root. Analyzing coredump '/var/spool/abrt/ccpp-2011-04-22-12:07:04-2100/coredump' Coredump references 3 debuginfo files, 1 of them are not installed Traceback (most recent call last): File "/usr/bin/abrt-action-install-debuginfo.py", line 422, in <module> result = downloader.download(missing) File "/usr/bin/abrt-action-install-debuginfo.py", line 200, in download self.repos.doSetup() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 72, in doSetup self.ayum.plugins.run('prereposetup') File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 184, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/auto-update-debuginfo.py", line 111, in prereposetup_hook _write_cached(cfname, rpmdbv, num) File "/usr/lib/yum-plugins/auto-update-debuginfo.py", line 86, in _write_cached fo = open(cfname + ".tmp", "w") IOError: [Errno 13] Permission denied: '/var/lib/yum/plugins/auto-update-debuginfo/num.tmp'
After restoring /var/spool/abrt-di/ and removing its contents, I am still getting a traceback running abrt-gui as root. selinux is enforcing, but there are no avcs in /var/log/messages and sealert doesn't report any. [joeblow@fir ~]$ ps -ef | tail joeblow 2382 2376 0 12:42 pts/0 00:00:00 bash root 2407 2 0 12:45 ? 00:00:01 [kworker/0:0] joeblow 2415 2376 0 12:46 pts/1 00:00:00 bash root 2440 2415 0 12:46 pts/1 00:00:00 sudo abrt-gui root 2444 2440 0 12:46 pts/1 00:00:00 abrt-gui root 2445 2444 1 12:46 pts/1 00:00:01 bug-reporting-wizard /var/spool/abrt/ccpp-2011-04-22-12:07:04-2100 joeblow 2459 2376 0 12:47 pts/2 00:00:00 bash root 2472 2 0 12:47 ? 00:00:00 [kworker/1:1] joeblow 2475 2459 0 12:48 pts/2 00:00:00 ps -ef joeblow 2476 2459 0 12:48 pts/2 00:00:00 tail [joeblow@fir ~]$ ls -alF /var/lib/yum/plugins/auto-update-debuginfo total 12 drwxr-xr-x. 2 root root 4096 Apr 22 11:35 ./ drwxr-xr-x. 3 root root 4096 Apr 22 10:22 ../ -rw-r--r--. 1 root root 48 Apr 22 11:35 num [joeblow@fir ~]$ ls -alFZ /var/lib/yum/plugins/auto-update-debuginfo drwxr-xr-x. root root unconfined_u:object_r:rpm_var_lib_t:s0 ./ drwxr-xr-x. root root unconfined_u:object_r:rpm_var_lib_t:s0 ../ -rw-r--r--. root root unconfined_u:object_r:rpm_var_lib_t:s0 num
(In reply to comment #4) > After restoring /var/spool/abrt-di/ ... I meant: [joeblow@fir cache]$ ls -lFd /var/cache/abrt-di drwxrwxr-x. 3 abrt abrt 4096 Apr 22 12:56 /var/cache/abrt-di/
this seems more like a problem with yum-plugin-auto-update-debug-info
yum-3.2.29-4.fc15.noarch yum-langpacks-0.2.2-1.fc15.noarch yum-metadata-parser-1.1.4-4.fc15.x86_64 yum-plugin-auto-update-debug-info-1.1.30-2.fc15.noarch yum-presto-0.6.2-3.fc15.noarch yum-utils-1.1.30-2.fc15.noarch
We had: if not os.access(cdname, os.W_OK): if os.path.exists(cdname): return try: os.makedirs(cdname) except (IOError, OSError), e: return ...and thought that was enough, just added the check on the open now too though.
James, we run our debuginfo-install script suided to "abrt", but keeping the original GID, can this be somehow confusing for yum? (now we set both uid and gid to "abrt" so it's hopefully fixed..)
Well we do os.access() calls in a number of places, which uses the "real uid/gid" instead of the "effective uid/gid" which will actually be used on the open() calls. Our assumption is that yum isn't used in any cases where the two differ (I know we haven't audited it for security problems like that). Saying that, we'll probably treat any cases like this as bugs anyway.
Thank you for the answer, we changed the code so now the effective and real uid/gid are set to the same value, so it shouldn't be problem anymore... let's see if it fixes some of the problems we have with yum ;)
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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