Kernel authorization in NetBSD

> 3. What can *YOU* do
>
>    If it wasn't implied already, these are some big,
heavy changes to
>    the tree. True: most of these are mechanical, and I
tried to mimic
>    the exact behavior we have now, in order to have
kauth(9)
>    transparently integrated. I've also stress-tested
the code on my
>    machines at home.
>
>    However... as with most stuff, breakage is usually
to be expected.
>    The code could still use some testing, especially in
configurations
>    that heavily utilize NFS or layared file-systems,
for example.
>
>    If it's not too much to ask, it would be *VERY*
helpful if people
>    could spend some of their time testing this branch a
bit before we
>    merge it.
>
>    To fetch the code from CVS, you should use:
>
>         cvs checkout -f -relad-kernelauth src
>
>    And then try to build a GENERIC kernel with the
DIAGNOSTIC option
>    uncommented. If you really feel crazy try DEBUG and
LOCKDEBUG.. 
>
>    Build a kernel and start using it... and report any
"anomalies" to
>    the list(s). Anomalies may include but are not
limited to:
>
>      - Unprivileged users can issue privileged
operations
>      - Machine panics, crashes, or hangs, in situations
it didn't before
>      - Things that used to work now don't work;
usually with an
>        "Operation not permitted" (EPERM)
error
>
>    So, again, if you have the time, *please* try it on
your own machine.
>
>

Could you give some more hints on specific areas where you
made
changes so we can come up with some more direct tests?  You
give some
hints about layered filesystems, but where else should we
look?
Just doing random stuff and waiting for failures isn't as
desirable.

Thanks,
_Matt