> I'd assumed (wrongly, apparently) that process_to_com would be a
> one-to-one mapping of process_id to command_id. If I look up the
> command name in the command table, it would seem that process 44 is
> both sshd and bash:

It's a PID roll-over problem. Since the target system re-uses PIDs as
processes spawn and die, and Walleye (in its current instantiation),
doesn't take PID rollover into account, then you end up getting multiple
commands associated with the same process_id in the databases... which
isn't the same as the PID on the target system.

I've been tinkering with this problem myself. I believe the only true
way to fix the problem would be to include more data in a sebek packet
(such as process creation timestamp), but that would mean mucking with
the protol yet again. If you want a work-around, let me know and I'll
dig up some ideas.

> There are also some processes absent from process_to_com entirely,
> like processes 7 and 12:

Sorry, don't know about that one.

-Frank p

[ reply ]