Pavel Machek wrote:
> > int my_callback(uint8_t pmEventID, void* pmStruct)
> ~~~~~
> You should return some value, if your return type is int ;-).
> It would be much nicer if you allowed for denying things, where it
> makes sense. Like packet came, callback returns 1, that means packet
> gets dropped. App does syscall, callback returns 1, syscall is
> denied. (I'm sorry if this is totally bad idea -- I did not look at
> patch).
It won't change much. The return value is there for future use,
but there is no current place in the kernel where the return
value is used and it's OK this way. Remember, we want to
instrument Linux without modifying it' behavior. If Linux
is to behave differently due to an event being traced, then
we've defeated the initial goal. Which doesn't preclude REacting,
which, itself, is different from acting.
You can still deny things using the current facility. Let's say you
absolutely want some process to be unkillable (for some security
auditing reason, for instance). Then you could write a module
that would hook itself with the process management events and
analyze what type of event it is. If it's a kill signal and it's
going to some process ID, then kill the sender. Hell, with this
even root wouldn't be able to kill processes. He'd have to unload
your module first. You could also arange to catch rmmods if you're
paranoid enough ...
Regards.
===================================================
Karim Yaghmour
karym@opersys.com
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
-
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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:16 EST