Oh boy, yet another uid, for those of us who weren't already
confused by the existing bestiary of uids and gids. :-)
I'm sure I'm missing something, but don't you get all the same
benefits (and more) from the following, conceptually simpler
mechanism:
Whenever a process changes any of its uid's, record its
pid, old-uids, and new-uids as an audit event.
Record all process-creation events, along with where they
inherited their uid's from.
Special processes like /bin/login can record extra events
whenever they like (e.g., where they would have called
setluid()/newsess_id()).
This gives you a tree of audit events.
Now, whenever you want to know the luid or sess_id for auditing
purposes, you can just walk back the tree in a user-level daemon.
Of course, the above scheme is more general than just luids/sess_ids,
and it supports other types of auditing than just the simple
luid/sess_id policy you outlined. But the point is that this
seems to be _policy_, and as such, shouldn't it live in user-space?
Ok, now you get to flame away. What am I missing?
-
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 : Sun May 07 2000 - 21:00:12 EST