Semantics of command_id, process_id, process_to_com, process_tree

On Fri, Jun 23, 2006 at 04:42:11PM -0400,
Valdis.Kletnieksvt.edu wrote:
> On Fri, 23 Jun 2006 15:16:08 EDT, "Frank S
Posluszny, III" said:
> 
> > > There are also some processes absent from
process_to_com entirely,
> > > like processes 7 and 12:
> > 
> > Sorry, don't know about that one.
> 
> Number *that* low on a Linuxoid kernel is almost
certainly a kernel
> thread (see kernel/pid.c and the use of RESERVED_PIDS
in alloc_pidmap()
> for all the gory details, but basically, all PIDs under
300 (by default)
> are reserved for kernel threads).   It's quite
possible that 7 and 12
> were threads created during boot to do things like scsi
initialization
> and so on (on my laptop, PID 8 is kblockd, and 9 is
kacpid, then a
> big jump to 117 cqueue and 120 khubd (USB support)).
> 
> If you're *really* curious to identify it, you'd have
to add instrumentation to
> kthread_create() in kernel/kthread.c and/or the
kernel_thread() function in
> arch/<mumble>/kernel/process.c - kernel_thread()
calls do_fork() which is
> what will end up assigning the PID to the thread.... 
You probably don't
> want to instrument do_fork() itself unless you plan to
spam yourself with
> printk output for *every* fork() you do.. ;)

I was under the impression that process_id as it appears in
the
database is strictly internal to the database, not the pid
of the
process on the host:

  mysql> select pid, process_id from process;
  +------+------------+
  | pid  | process_id |
  +------+------------+
  | 5952 |          1 | 
  | 5788 |          2 | 
  |    0 |          3 | 
  | 5953 |          4 | 
  | 5954 |          5 | 
  | 5709 |          6 | 
  |    1 |          7 | 
  | 5562 |          8 | 
  | 5866 |          9 | 

and process_to_com refers to this database process_id, not
the
kernel's process id...  or?

-troy

troy d. straszheim said the following on 6/23/2006 4:53 PM:
...
> I was under the impression that process_id as it
appears in the
> database is strictly internal to the database, not the
pid of the
> process on the host:
...

You're right.  The process_id is assigned on the honeywall
by the
sebekd.pl script (iirc), which determines if the data it is
seeing is
associated with a new process.

So here's what I'm guessing is happening with your
process_id with no
name...
A sebek packet comes in and it contains a pid that has not
been seen
before, so a new process_id is associated with it and
appropriate
entries are made in the command_id table.  During this
processing, the
ppid is identified as being a new process, and so a new
process_id is
associated with it.  However, there is no command name in
the sebek
packet for the ppid, so no command_id entry is created.

That make sense?

-Frank p