On Tue, 2011-01-04 at 13:56 +0100, Nikola Pajkovsky wrote:
On Mon, 03 Jan 2011 16:55:14 +0100, Denys Vlasenko
<dvlasenk(a)redhat.com> wrote:
> I propose the following solution: crash dumps creation is not changed:
> they are still created in /var/spool/abrt/*. Root user can process them
> there, in-situ.
>
> 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
> dump /var/spool/abrt/USER'S_CRASH_DUMP".
>
> >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 /
> any_other_action) immediately".
>
> Do you see any problems with this approach?
Maybe I don't fully understand. Why do you want to *move* it?
Because program which runs under non-root cannot
dd_opendir() a dump dir in /var/spool/abrt/.
It can only operate on some writable directory.
It will lead to that admin won't see crash.
Yes. But only for those crash dumps which were "stolen".
Presumably, if user (as opposed to root) "stole" crash dump,
user is going to deal with it, not root.
But not ever crash dump will be "stolen".
Basically, use cases fall into two categories which usually do not
intersect:
- Root-administered machines (like web servers): even though there are
processes running (and crashing) under non-root accounts, there are no
real people logging in and working ar non-root. Admin logs in as root
and deals with crashes.
In this case, stealing is not needed and never happens.
- Shared machines (e.g. personal laptops; student labs): there are
non-root users. Some of them will want to report crasher they
experience - they use "stealing" to take crashes from /var/spool/abrt/
to their $HOME, and report and/or delete them.
Other users don't - root deals with their crashes, without using
stealing. For example, this is the case for all "machine" accounts
which do not correspond to real people.
Another things what's come up. How we will sync crash dump?
We won't sync anythin. "Stolen" dump dir is no longer visible to root.
As far as root is concerned, user's dump dir was deleted by the user.
One thing what's good now is, that we have crash
dump in sync with users. When user do whatever with dump dir, admin
doesn't see that.
Yes, this property is lost.
Do you have an idea how to do it better?
--
vda