Bear in mind that people are trying to lock down Linux with serious
security, such as mandatory access control. The Coda filesystem
developers seem to want each login to be isolated from every other.
Perfect matches are very reliable. Anything less is likely to
allow mistakes.
>> 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,
I highly doubt that root will want to steal core dumps.
For embedded systems, non-root simply won't run a crash handler.
In any case, "chmod 600 /dev/crash" if you want to steal cores.
It is more likely that root will be too lazy to run the daemon.
I'd hate to rely on certain admins I know.
>>> 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
See, _that_ is the problem. An orderly chain is featuritis.
> 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
Yes, that would be a mess. Don't do that.
> rather have any such logic in user-space, meaning a root daemon that
> spawns or communicates with minimum security processes.
That logic does not belong anywhere. It is overly complex.
This is simple:
1. Look for an exact security match.
2. If none, look for root.
3. If not found, dump core.
Step 2 is really for setuid programs and servers that change UID.
It is not intended to catch normal user processes. In fact, it
should just dump a standard core if it catches one by accident.
-
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/