Subject: Re: kern.showallprocs implementation
To: Rui Paulo <rpaulo@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/29/2005 19:03:29
Content-Type: text/plain; charset=us-ascii
On Tue, Aug 30, 2005 at 01:50:12AM +0100, Rui Paulo wrote:
> On 2005.08.29 17:05:35 +0000, Bill Studenmund wrote:
> | security.bsd.what? What name do you propose for the last component?
Please, use one knob. Or please explain to me a realistic situation where=
we want one yes and the other no.
Really, please explain a likely case where we want one blocking and not=20
All the times I can think I'd like to deny a proc/user knowledge about=20
other processes, I also want to deny that proc/user knowledge about open=20
sockets (and file descriptors and all the other things we can think to=20
extend this to).
Say the admin blocks process visibility. If I can still see there's an
open listen socket on tcp/80, what do you bet there's a web server on the
box? Likewise, say I block sockets visibility but not process. If I see=20
"httpd" in ps, what do you bet something fun is at 80, 8000, or 8080? :-)
So I think if we want blocking, we want all blocks on or all off.
While it doesn't matter much with just two knobs, I already would love us=
to add fstat support. So that would be a third knob. Then we add it to=20
another subsystem, and we have a fourth knob. And so on.
So we will have all these knobs, and we want to flip them all the same way=
all the time. Thus it strikes me as error-prone to have a lot of switches=
that need to be flipped together. It seems much safer to make one big=20
I agree there is an intelectual purity to having separate knobs for each=20
subsystem. However I think we'll be better off making one knob for now.
Also, we are taking an incrimental step. Let's add the one knob, then we=20
can add sub-knobs if we find applications that need them. We are, after=20
all, going to evolve the interface. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----