Re: [logs] adduser log

betat_private

2003-01-22T13:50:49 Tom Perrine:
> It really depends on whether you do just exec() or other system
> calls.  Doing more than just a few calls will get ugly, really fast.

Sure enough. Exec() has the feature of offering the biggest bang for
the buck, in many contexts.

> Its not clear (yet), if this would be a problem if you just did
> exec(), but I *could* also argue that if you are doing exec(), why
> not chmod() and chown(), and then open()? :-(

Arranging to be able to [optionally!] log all execve(2) calls gives
you a lot of valuable intelligence with minimum load; the list of
programs executed, by whom, when, tells a lot. Not everything of
course; swiss-army-chainsaw programs (interpreters for languages
with a rich assortment of builtin primitives: perl, tcl, python,
ruby, ...) conceal much. But in routine operation a log of execs
would offer great value to some shops. I've been at some.

> Consider that lots of kernels are idling at hundreds or thousands
> of system calls/sec.

Those are the syscalls we don't want to try to log.

Any idea what the exec() rate is for a typical system?

Depends wildly on what you're execing. exec has to set up a new
process image loaded (or paged) from a named executable file. If you
were to benchmark execs of the smallest, simplest possible program,
you'd get numbers probably thousands of times faster than real
typical execs. The limiting case is probably governed by the data
segments; for my system, the mean data size in /usr/bin is about
15KB. Once I get execve logging going, I'll make a weighted average
by frequency of invocation of executables:-).

But making a single log for each execve should be affordable.

> Note that exec() is one of the most expensive system calls there
> is, so saying that your added overhead is compariticely low isn't
> saying an awful lot :-)

Actually, I think that's the essential point. For characterizing
what's being done on a system, execve is a good first step; and yet
it should be affordable.

-Bennett