In current git, crash dumps are always processed by the daemon,
which runs under root. Clients merely send commands to daemon.
This poses the security problem: a lot of code
runs under root and auditing it all for safety is
a non-trivial task, which will be a constant burden during
Worse, it makes code unnecessarily complex.
Consider abrt-action-print: it has -o OUTFILE option.
With current arrangement, we either should prohibit its usage
altogether to prevent overwriting of arbitrary files,
or add code which checks that the file is writable
*by the user which issued the dbus command to daemon*! So, we need to do
something like pass down $UID to all children, and don't forget to check
it everywhere. This wouldn't be pretty, and easy to get wrong.
Therefore we decided to try to migrate crash dump processing
to user side. IOW: we want to run events on crash dumps
by clients themselves - without any talking to daemon.
As Jiri reported, when he tried to do this, one problem
he immediately stumbled upon is that currently crash dumps
are created under uid:gid and mode which make them non-writable
by user. And we _do_ require writing to crash dumps for any nontrivial
This mail discusses one possible way to overcome this problem.
At least one kind of crash dumps - C/C++ dumps - is created by
kernel hook and therefore it might be unable to access $HOME.
This rules out creation of crash dumps somewhere inside user home
directories. Even if this problem would not exist and we could save
crash dumps in, say, $HOME/.abrt/spool/*, we would lose
a property that admin (root) can see all crashes (with any uids)
in one place.
I propose the following solution: crash dumps creation is not changed:
they are still created in /var/spool/abrt/*. Root user can process them
Non-root users can not, but they can "steal" their crashes:
by copying/moving them to $HOME/.abrt/spool/*. This is the only
operation which requires cooperation from daemon. Copying
itself can be done by client-side program without any help
from daemon if /var/spool/abrt/USER'S_CRASH_DUMP directory is readable;
deleting requires help from daemon. We end up needing only one
command sent from client to daemon: "please delete crash
>From the non-root user's perspective, working with crash dumps will look
like this: there is a GUI app which shows the list of all crashes. It is
built by scanning both /var/spool/abrt/* and $HOME/.abrt/spool/*.
User can click on any element of the list and open a window (this most
likely runs a separate GUI program) to handle selected crash; or they
can delete any element of the list.
Those crashes which reside in $HOME/.abrt/spool/* can be acted upon
(reported / deleted / any_other_action) immediately; those
from /var/spool/abrt/* need to be "stolen" first - moved
from /var/spool/abrt/* to $HOME/.abrt/spool/*. GUI asks for confirmation
before doing it. (Maybe it makes sense to separate "copy" and "delete"
steps which comprise "move" operation and allow user to do only "copy",
or only "delete"? -> more power to user?). "Delete" step is implemented
by sending a command to daemon to delete specified /var/spool/abrt/*
directory. It's the only operation which needs help from daemon side.
(Theoretically, we can have a tiny specialized suid-root binary for this
operation instead, doing away with needing a running daemon).
After "stealing", crash resides in $HOME/.abrt/spool/* and we end up
with simple case of "can be acted upon (reported / deleted /
Do you see any problems with this approach?