Bill Studenmund wrote:

> Elad, please be VERY careful with comments like this. I've seen comments
> like this come by in the past, something happen to the developer intending
> to work on X (something gets in the way of the work), and so "very near
> future" turns into years, with no improvement to NetBSD in the mean time.

I wouldn't make such a comment if I didn't plan on doing the exact same
thing, in a more generic and extendable way, very soon.

> "I think these changes will be a mistake" is a good reason to not make a 
> change. "I want something better," when we don't have code for "better," 
> doesn't seem like a good reason.

How about "I don't like the way FreeBSD did it. I'd rather have a
kern.privacy node where we could set filters for various parts of the
system that use sysctl"?

One of the things I'm doing is changing kvm(3) use for live kernel reads
to sysctl(3) calls. I've done this for PF_INET in netstat. Some people
want to be able to filter connections not owned by the user. Do you
think we should add a kern.showallinetconnections as well?

> Elad, would this change HURT the "broader" change you have in mind?

Yes, because users will get used to something.

> If 
> not, let's add this for now and then when you have code, we can review it 
> and let it replace this change.

When did this become so urgent? If it is, I'll commit code *now*.
However, I don't think this is critical enough to be a top priority,
especially not when I'd rather something like this be well designed.

The same project from which we imported most of the new Veriexec also
had privacy hooks. The code is already written and tested, but as I
said - if this is something that gets into base, let's think it a bit
more than an ugly ``showallprocs'' knob...

-e.

-- 
Elad Efrat
PGP Key ID: 0x666EB914