> Kenneth Albanowski writes:
>
> > Making the character device world accessible might not be quite right,
> > though, unless the kernel allows multiple connections, and automatically
> > gives each connected daemon from the one with the most authority (root
> > perms) to the least (user perms) a chance at taking the uid, in turn.
>
> World accessible with multiple connections is totally correct.
> Only an exact authority match is acceptable. If you run a setuid
> app and want to catch crashes, you need a setuid daemon to do it.
I'm not sure that degree of precision is needed. A deamon with the uid/gid
that the app was set to (as opposed to what it is running as) should be
sufficient. A setuid daemon would then work too, of course.
> Possible exception: root (well, CAP_DEBUG_ANY) could ask to accept
> anything left over. Users always get first chance.
Hmm. I'd like to say that root is root, and gets control first, and it
spirals in from there, with the user being last. Of course that isn't
quite right, as the user may very well be using the this mechanism for
something (like persistance) that the kernel's handler (core-dump, let's
say) is inappropriate for. Maybe a spiral inwards and then back outwards,
with a presumption that the administrator is sane and put the core dumper
in at the end, instead of the beginning? And I'm not sure whether there
can be less/more security, or just root/user. Where do groups come in?
However, I'm not sure any of this matters much, at least to the in-kernel
side. See below.
> > It's probably simpler to have a root daemon that uses /etc/debugconf,
> > ~user/debugconf, etc., to figure out what processes get which treatment.
>
> Ugh. You get an authorization mess, with a user-space tool trying to
> verify permission. I don't think it is good for a root daemon to mess
> with user home directories. (not that it can always be avoided of course)
Agreed, the problem is that if we want a nice orderly chain between
different crash handlers (each possibly deciding to skip the process or
just record some data, then handing it off to the next in line), we
_don't_ want the kernel responsible for coping with this, because then the
kernel must make sure nobody is playing silly buggers and not passing
control around until next Tuesday, or something equally stupid. I'd much
rather have any such logic in user-space, meaning a root daemon that
spawns or communicates with minimum security processes. There's no problem
with setuid or any other tasks, as ptrace() has perfect security, in any
case.
I think the character device can consist solely of the kernel sending out
a pid to the reader. It automatically puts the task in stasis and promptly
forgets about it. The daemon takes responsibility of doing anything with
the task that it wants to. When everyone is done with it (to the daemon's
satisfaction), the task can be thawed and allowed to die by sending it any
signal. (If a core is needed, that's handled by a new ptrace sub-command,
which doesn't implicitly kill the task.)
Note that there is a specific contract here: if anyone is listening on the
device, they take the responsibility of thawing out and killing the tasks.
Otherwise the corpsicles will pile up. (They are limited by quota, and can
be removed by any signal, so they aren't a risk, just annoying.)
If we do want some level of multiple-reader support within the kernel,
perhaps you can do it by making the device a clearing-house of sorts. It
allows multiple readers, and sends the pid to the "first" reader (root or
user, whichever). If that reader decides to pass control on to the next
hander, it writes the pid back into the device. The driver makes sure the
pid corresponds to a frozen process, goes through the security checks, and
sends the pid on to the _next_ reader that deserves it. If there isn't
such a next reader, it thaws the process, letting it die (without dumping
core).
This approach won't require any lists to be stored, as the "next handler
in sequence" is computed anew each time based on who wrote in the request,
and the security details of the still-frozen process. However, there may
be some security issues involved with writing in a "guessed" pid and
causing race conditions to make the driver skip sending notification to a
handler. I'm not sure if this would be considered a significant problem.
Hmm. I guess one extra long per task would be enough to store the pid of
the last task that is the current "death handler", making it impossible to
trick the driver into skipping handlers.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/