Hide Forgot
Description of problem: abrt displays this message when attempting to download debuginfo packages: Need writable directory, but '/var/spool/abrt/ccpp-2011-03-29-13:47:38-2362' is not writable. Move it to '/home/joeblow/.abrt/spool' and operate on the moved copy? User joeblow is in group joeblow, but group joeblow does not have write permission: [joeblow@fir abrt]$ pwd /var/spool/abrt [joeblow@fir abrt]$ ls -alF total 32 drwxr-xr-x. 7 abrt abrt 4096 Mar 30 14:15 ./ drwxr-xr-x. 14 root root 4096 Mar 29 13:17 ../ drwxr-x---. 2 abrt joeblow 4096 Mar 30 14:15 ccpp-2011-03-29-13:47:38-2362/ drwxr-x---. 2 abrt root 4096 Mar 30 14:15 ccpp-2011-03-29-13:57:16-1251/ drwxr-x---. 2 abrt joeblow 4096 Mar 30 14:15 ccpp-2011-03-29-14:45:55-23694/ drwxr-x---. 2 abrt joeblow 4096 Mar 30 14:15 ccpp-2011-03-29-15:55:36-1595/ drwxr-x---. 2 abrt joeblow 4096 Mar 30 14:15 ccpp-2011-03-30-14:15:50-1559/ -rw-------. 1 root root 20 Mar 30 14:15 last-ccpp [joeblow@fir abrt]$ cd ccpp-2011-03-29-13:47:38-2362/ [joeblow@fir ccpp-2011-03-29-13:47:38-2362]$ touch foo touch: cannot touch `foo': Permission denied [joeblow@fir ccpp-2011-03-29-13:47:38-2362]$ 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 ccpp-2011-03-29-13:47:38-2362]$ Version-Release number of selected component (if applicable): abrt-2.0.0-2.fc15.x86_64 abrt-addon-ccpp-2.0.0-2.fc15.x86_64 abrt-addon-kerneloops-2.0.0-2.fc15.x86_64 abrt-addon-python-2.0.0-2.fc15.x86_64 abrt-desktop-2.0.0-2.fc15.x86_64 abrt-gui-2.0.0-2.fc15.x86_64 abrt-libs-2.0.0-2.fc15.x86_64 abrt-plugin-bugzilla-2.0.0-2.fc15.x86_64 abrt-plugin-logger-2.0.0-2.fc15.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I worked around this problem with: [joeblow@fir abrt]$ sudo chmod g+w ccpp*
This is actually not a bug, but a correct behavior, files in /var/spool/ shouldn't be writable by ordinary users/groups. you can just press 'y'or button yes - depends on if you using cli or gui and let abrt move the directory.. btw, it has nothing to do with downloading debuginfo, it is downloaded to the /var/cache/abrt-di, the question you're seeing is because abrt tries to write the backtrace into /var/spool/abrt/ccpp-2011-03-29-13:47:38-2362
(In reply to comment #2) > This is actually not a bug, but a correct behavior, files in /var/spool/ > shouldn't be writable by ordinary users/groups. you can just press 'y'or button > yes - depends on if you using cli or gui and let abrt move the directory.. OK, so why is abrt complaining that ccpp-2011-03-29-13:47:38-2362 is not writable?
All bugs are initially saved into /var/spool/abrt which can't contain writable directories for unprivileged users. When you are reporting a bug ABRT needs to write in the directory where the data are stored and since it can't write to /var/spool/abrt/ccpp-* it's asking you if it can move the directory to $YOURHOME/.abrt/spool/ccpp-* so it can write into it.
(In reply to comment #4) > All bugs are initially saved into /var/spool/abrt which can't contain writable > directories for unprivileged users. When you are reporting a bug ABRT needs to > write in the directory where the data are stored and since it can't write to > /var/spool/abrt/ccpp-* it's asking you if it can move the directory to > $YOURHOME/.abrt/spool/ccpp-* so it can write into it. OK, thanks. The behavior has changed since F14. I am reopening, because the wording is confusing -- it asks a question to which the answer "no" results in no bug report being filed. Indeed, why ask at all?
*** Bug 702530 has been marked as a duplicate of this bug. ***
It's annoying to answer this question for every bug report. I favor either removing it altogether or asking it only once, as a matter of policy. Something like: ABRT must write (temporary?) files to WHEREVER in order to submit bug reports. May ABRT do this? But now, as I write this, I'm having a bit of windows Deja Vu: ABRT is attempting to write files to WHEREVER, confirm or deny?
(In reply to comment #4) > All bugs are initially saved into /var/spool/abrt which can't contain writable > directories for unprivileged users. why? - IMHO, this is in violance with FHS http://pathname.com/fhs/pub/fhs-2.3.html#VARSPOOLAPPLICATIONSPOOLDATA "Data in /var/spool represents work to be done in the future (by a program, *user*, or administrator);" how can user process data which aren't writable by the user?
If you click "OK" the directory is copied to your home and daemon removes the original files in /var/spool/. We can't make it writeable in /var/spool/ because having a directory in /var/ writeable by non-root is dangerous. So to me it's not a violation of FHS - the directory is meant to be processed later...
(In reply to comment #9) > If you click "OK" the directory is copied to your home and daemon removes the > original files in /var/spool/. We can't make it writeable in /var/spool/ > because having a directory in /var/ writeable by non-root is dangerous. you mean like /var/tmp? :-) we have the ownership restrictions, we have selinux (hopefully turned on), how is that more dangerous than having a directory writable by user anywhere else? - could you refer to some docs please?
I guess if it's moved it should be moved to a cache or a temp directory.What are the reasons the user might not want it copied to their home directory? Two reasons I can think of off the top of my head are the space used by the dump and the io needed to copy it. Ideally I guess you want them moved somewhere else on /var as its most likely to be on the same fs (and hence mv is cheap)?
The gui now has the ability to remember the settings, so we can implement the "Don't ask me again" checkbox as the first step.
Upstream commit aefcee71e97e517b3ba3f7d6d0957d27de1fd025.
abrt-2.0.7-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abrt-2.0.7-2.fc16
Package abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16: * should fix your issue, * was pushed to the Fedora 16 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.7-2.fc16 libreport-2.0.8-3.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16990/libreport-2.0.8-3.fc16,abrt-2.0.7-2.fc16 then log in and leave karma (feedback).
abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.