Hey Peter,
> Before I replied, I wanted to make sure I could discuss this on the
> opensolaris aliases. The code I am working with is Kerberos code that
> we have license to work with and is in the public domain, so I am
> cleared to go.
>
> The overall problem:
>
> Data corruption of an internal kerberos database was experienced, and
> analysis of existing data did not yield any conclusive root cause to the
> problem.
>
> Next step action plan:
>
> We wanted to develop a dtrace script that would capture the raw data
> that would be used to modify the internal database just before it was
> actually used to update the database. I have written this script, and
> it does dump out the record. However, it turns out that the database
> can be modified by three different methods, and each of these can be run
> many times under different pid numbers of course. The three methods are
> kadmin, kadmin.local and kpasswd.
Thanks for the use case! One thing to investigate: add an SDT probe in
the common library where the database is modified. Especially with
is-enabled probes, you can construct this such that it provides rich
arguments (e.g., the nature of the query or transaction) -- and then the
ability to dynamically instrument all processes that make the call just
falls out.
And to be honest, it's such a nasty problem to allow instrumentation of
arbitrary functions across arbitrarily many (and arbitrarily dynamic)
processes that we're unlikely to solve it (at least in the near future) --
especially with SDT probes providing such a reasonable solution...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
