Re: [PATCH] some cleanup + antiforkbomb

|Daniele,
|I was  thinking about  this just this  morning.

that's what the computer scientist calls "Distributed Shared Memory" :)

| Moreover I  think the
|design has to be chosen properly in order to avoid strange behaviours.

absolutely agree

|What I thought is to implement  a memory-based char device using it as
|a "memory buffer" (for those  who read Rubini's "Linux Device Drivers"
|something  similar to  scull module).   If we  allocate memory  with a
|GFP_ATOMIC flag  we're quite sure it'll  work properly in  any kind of
|context be it process context or interrupt context. And this is a cool
|thing IMHO  since it'll  avoid any future  trouble we could  have with
|logging.

Angelo, your idea is great .. but i still believe that the
"Unkillable Kernel Thread" is the better solution since:
- it allows to impose a rate_limit to avoid DoS 
  (example: an excessive flood of logging messages)
- it allows to avoid dumping of the same log message twice
- what happens if the user space application dies?
- Using a memory buffer implies a circular buffer
  which is not safe in this situation. What happen at each
  round?
- if we want to use a user_space facility (to capture the angel
  log messages) IMHO a netlink socket is the better solution
  and again: a kernel_thread is required.

btw i believe that the actual angel_log should be replaced
(this is especially nedded for chrooted processes)

|Obviously the read method should be implemented in such a way
|as to  flush this "memory  buffer". For performance reasons,  we could
|think just moving the file offset  to the beginning of the buffer thus
|simply  overwriting yet  allocated  memory.  And  another really  cool
|thing is  to define a  poll method for  such device.  In this  way, we
|could write a simple user-space daemon which avoids polling the device
|but, using I/O  multiplexing concepts, could block in  a select(2) for
|readability.

your idea is good, but the kernel_thread solutions doesn't require
a lot of rework.
It gives the same results (using a netlink socket) and also give
more functionality needed for angel.

|In this situation, I don't think we need a kernel thread.. but I could
|be wrong..

me too :)

|PS Just for your fun...
|"Debugging is  twice as hard as  writing the code in  the first place.
|Therefore, if you write the code  as cleverly as possible, you are, by
|definition, not smart enough to debug it." - Brian W. Kernighan

"Kernighan The Best, and fuck the rest" :)

-- 

Daniele.




"I could have made money this way, and perhaps amused myself writing code. 
But I knew that at the end of my career, I would look back on years of 
building walls to divide people, and feel I had spent my life making the 
world a worse place."                               
                                                          Richard Stallman


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List