Edward G. Balas said the following on 6/23/2006 3:45 PM:
...
> Walleye is simply rendering what hflowd and sebekd put
in the database, so
> if there is a problem with PID rollover then its likely
in sebekd.
>
> Never is it the case that 2 processes will use the same
PID at the same
> point in time, on the same system, so if there is a bug
in sebekd there
> should
> be hope that it can be fixed without a protocol
modification.
...
Sure, it's a sebekd problem, but I do not believe it can be
solely fixed
there. For that to happen, it would need enough information
to decide
when a PID refers to a new process versus one that is
already in the
database. Right now, the sebek protocol sends these bits of
information
(amongst others): parent PID, PID, UID, and command name.
I believe that with this information, one can not know
_for_certain_
that a packet is related to a currently known process or a
new one. We
could assume that, in a given amount of time, a process will
not die and
a new process will be spawned by the same parent, will be
given the same
process ID, will have the same associated UID, and will have
the same
command name... but there is no guarantee. I am also
thinking that with
a simple timer, you have to assume that any packets coming
in after the
time expiry are for a new process, even if they are for the
same one.
That's why I believe adding more information to the mix
would alleviate
the problem. For instance, the combination of PID and
process creation
timestamp would be enough to identify a single process...
assuming fine
enough granularity of the timestamp.
This is a topic that really interests me, so I would love to
hear /
discuss other implementation ideas / critiques.
-Frank p
|