Description of problem: Getting "Permission denied" when running abrt-gui from the command line. The user is not privileged, but is in group wheel. selinux is enforcing, but there are no alerts. A full relabel has been done. The GUI seems to run normally. Version-Release number of selected component (if applicable): abrt-2.0.1-1.fc15.x86_64 How reproducible: Always. Steps to Reproduce: 1. $ abrt-gui Actual results: "Permission denied" messages. Expected results: No messages. Additional info: [joeblow@fir ~]$ abrt-gui Can't access '/var/spool/abrt/ccpp-2011-04-18-11:53:22-2661': Permission denied Can't access '/var/spool/abrt/pyhook-2011-04-18-10:24:27-1530': Permission denied Can't access '/var/spool/abrt/ccpp-2011-03-30-16:12:54-1198': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-18-15:13:46-2167': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-10-03:01:01-6548': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-07-06:11:46-1759': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-06-13:26:50-2829': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-18-15:13:15-1903': Permission denied Can't access '/var/spool/abrt/ccpp-2011-04-18-16:48:41-2824': Permission denied Can't open file '/var/spool/abrt/ccpp-2011-03-29-13:57:16-1251/time': Permission denied Can't open file '/var/spool/abrt/ccpp-2011-03-29-13:57:16-1251/reason': Permission denied [joeblow@fir ~]$ id uid=500(joeblow) gid=500(joeblow) groups=500(joeblow),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [joeblow@fir ~]$ ls -alF /var/spool/abrt/ total 17484 drwxr-xr-x. 13 abrt abrt 4096 Apr 20 12:12 ./ drwxr-xr-x. 14 root root 4096 Apr 5 03:47 ../ -rw-r--r--. 1 root root 12595200 Mar 31 13:50 abrt-action-bugzilla-coredump-1 -rw-r--r--. 1 root root 12587008 Apr 1 04:20 abrt-action-bugzilla-coredump-2 -rw-r--r--. 1 root root 12636160 Apr 1 05:54 abrt-action-bugzilla-coredump-3 -rw-r--r--. 1 root root 12718080 Apr 4 11:23 abrt-action-bugzilla-coredump-4 -rw-r--r--. 1 root root 1728512 Apr 20 12:09 abrt-applet-coredump -rw-r--r--. 1 root root 1732608 Apr 5 14:12 abrt-applet-coredump-1 drwxr-xr-x. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-03-29-13:57:16-1251/ drwxr-x---. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-03-30-16:12:54-1198/ drwxr-x---. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-04-06-13:26:50-2829/ drwxr-x---. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-04-07-06:11:46-1759/ drwxr-x---. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-04-10-03:01:01-6548/ drwxr-x---. 2 joeblow joeblow 4096 Apr 20 13:33 ccpp-2011-04-12-09:30:39-1814/ drwxr-x---. 2 abrt gdm 4096 Apr 19 13:04 ccpp-2011-04-18-11:53:22-2661/ drwxr-x---. 2 abrt gdm 4096 Apr 19 13:04 ccpp-2011-04-18-15:13:15-1903/ drwxr-x---. 2 abrt gdm 4096 Apr 19 13:04 ccpp-2011-04-18-15:13:46-2167/ drwxr-x---. 2 abrt root 4096 Apr 19 13:04 ccpp-2011-04-18-16:48:41-2824/ -rw-------. 1 root root 20 Apr 20 12:09 last-ccpp drwxr-x---. 2 abrt root 4096 Apr 19 13:07 pyhook-2011-04-18-10:24:27-1530/ [joeblow@fir ~]$ ls -alFZ /var/spool/abrt/ drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 ./ drwxr-xr-x. root root system_u:object_r:var_spool_t:s0 ../ -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-action-bugzilla-coredump-1 -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-action-bugzilla-coredump-2 -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-action-bugzilla-coredump-3 -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-action-bugzilla-coredump-4 -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-applet-coredump -rw-r--r--. root root system_u:object_r:abrt_var_cache_t:s0 abrt-applet-coredump-1 drwxr-xr-x. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-03-29-13:57:16-1251/ drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-03-30-16:12:54-1198/ drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-06-13:26:50-2829/ drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-07-06:11:46-1759/ drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-10-03:01:01-6548/ drwxr-x---. joeblow joeblow system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-12-09:30:39-1814/ drwxr-x---. abrt gdm system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-18-11:53:22-2661/ drwxr-x---. abrt gdm system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-18-15:13:15-1903/ drwxr-x---. abrt gdm system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-18-15:13:46-2167/ drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 ccpp-2011-04-18-16:48:41-2824/ -rw-------. root root system_u:object_r:abrt_var_cache_t:s0 last-ccpp drwxr-x---. abrt root system_u:object_r:abrt_var_cache_t:s0 pyhook-2011-04-18-10:24:27-1530/ [joeblow@fir ~]$
I reproduced this as follows after renaming /var/spool/abrt and rebooting. As a normal user: [joeblow@fir ~]$ sleep 1000 & [1] 1728 [joeblow@fir ~]$ kill -6 1728 [joeblow@fir ~]$ abrt-gui [1]+ Aborted (core dumped) sleep 1000 [joeblow@fir ~]$ [joeblow@fir ~]$ abrt-gui Lock file '/home/joeblow/.abrt/spool/ccpp-2011-04-20-13:48:58-1728/.lock' is locked by process 1770 Lock file '/home/joeblow/.abrt/spool/ccpp-2011-04-20-13:48:58-1728/.lock' was locked by process 1791, but it crashed? As root: [joeblow@fir ~]$ su - Password: [root@fir ~]# sleep 1000 & [1] 1933 ... # kill -l output omitted [root@fir ~]# kill -6 1933 [root@fir ~]# date Wed Apr 20 13:56:41 PDT 2011 [1]+ Aborted (core dumped) sleep 1000 [root@fir ~]# logout [joeblow@fir ~]$ [joeblow@fir ~]$ [joeblow@fir ~]$ abrt-gui Can't access '/var/spool/abrt/ccpp-2011-04-20-13:56:19-1933': Permission denied [joeblow@fir ~]$ ls -alF /var/spool/abrt/ total 16 drwxr-xr-x. 3 abrt abrt 4096 Apr 20 13:56 ./ drwxr-xr-x. 15 root root 4096 Apr 20 13:47 ../ drwxr-x---. 2 abrt root 4096 Apr 20 13:56 ccpp-2011-04-20-13:56:19-1933/ -rw-------. 1 root root 10 Apr 20 13:56 last-ccpp
This is not a bug, these directories just don't belong to the user running the gui. We should just suppress these messages so they don't confuse users..
Fixed in upstream git.
abrt-2.0.2-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/abrt-2.0.2-1.fc15
Package abrt-2.0.2-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.2-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/abrt-2.0.2-1.fc15 then log in and leave karma (feedback).
abrt-2.0.2-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/abrt-2.0.2-3.fc15
I have had this problem since before F15 was released. I still have it now on Name : abrt Arch : x86_64 Version : 2.0.2 Release : 5.fc15 In lieu of opting for change to /home/username/.abrt/spool upon failure of permissions for /var/spool/abrt/ccpp-*, maybe ABRT should check the user filing against root/administrator group/or automatically configure to the user's local directory.
This was discovered earlier at the bottom of the page here http://fedoraproject.org/wiki/Test_Day:2011-03-31_ABRT_Retrace_Server. Just Ctrl-F "/var/spool/abrt/ccpp". ...forgotten to link earlier.
im having the sam problem with fedora 16 cant access /var/spool/abrt/ chmod: cannot access `/var/spool/arbt
(In reply to comment #9) > im having the sam problem with fedora 16 cant access /var/spool/abrt/ > chmod: cannot access `/var/spool/arbt which abrt version? when do you see the message "chmod: cannot access '/var/spool/abrt' ? I'm not aware of any code in abrt which would try to chmod the directory
(In reply to comment #10) > (In reply to comment #9) > > im having the sam problem with fedora 16 cant access /var/spool/abrt/ > > chmod: cannot access `/var/spool/arbt > > which abrt version? when do you see the message "chmod: cannot access > '/var/spool/abrt' ? I'm not aware of any code in abrt which would try to chmod > the directory it happned while retracing a server ......here is the discription -- Running analyze_RetraceServer --- Querying server settings Preparing an archive to upload Uploading 5 megabytes Uploading 10% Uploading 16% Uploading 22% Uploading 27% Uploading 33% Uploading 39% Uploading 45% Uploading 50% Uploading 55% Uploading 60% Uploading 65% Uploading 71% Uploading 75% Uploading 80% Uploading 84% Uploading 90% Uploading 96% Upload successful Retrace job started Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Initializing virtual root Retrace job failed Retrace failed. Try again later and if the problem persists report this issue please. Analyzing crash data OK Initializing virtual root OK Generating backtrace Error Unable to chmod the executable (exited with 1)
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
thanks for resolving this bug. recently just faced a similar issue when doing a project for http://buycollegeessay.org/ . had no idea what to do but now know where to start in order to fix it
It was great to see this issue resolved. Recently, I faced something similar when doing a project for https://egum.com. Now I know where to start.
Your site is very interesting and effective, Thanks for sharing! https://nature-rangers.org/camp/ https://nature-rangers.org/camp/