Subject: Re: kern.showallprocs implementation
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 08/29/2005 13:42:04
--yH1ZJFh+qWm+VodA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 29, 2005 at 08:51:44PM +0300, Elad Efrat wrote:
> Bill Studenmund wrote:
>=20
> > The one comment I have is in repsponse to the name. I suggest we go wit=
h=20
> > something similar to what FreeBSD has:
> >=20
> >      security.bsd.suser_enabled 	      integer	    yes
> >      security.bsd.see_other_uids	      integer	    yes
> >      security.bsd.unprivileged_proc_debug     integer	    yes
> >      security.bsd.unprivileged_read_msgbuf    integer	    yes
> >=20
> > Obviously we don't have to have all of these nodes. But=20
> > "security.bsd.see_other_uids" seems about as good as "kern.privacy.proc=
".
>=20
> I'd like to have a ``security'' node; but that's about it. :)
>=20
> > I think it would be appropriate to have one knob control both the proce=
ss=20
> > and socket ownership features in your (Elad's) code.
>=20
> Why? You can have one big knob and multiple smaller knobs so you can
> tune privacy the way you want it.

Because we are differing from prior art, and it is not at all clear to me=
=20
how often folks will want separate smaller knobs. Yes, different knobs can=
=20
be cool if there are times when we want to flip one of them and not=20
another. But if we always end up tuning them both together, then we=20
actually only make things harder for our users.

If I don't want user X to see other users' processes, why would I want
that user to see network sockets owned by other users? Port numbers can=20
tell you a lot about what is going on. If I see something on port 80, well=
=20
I have a web browser. And so on.

Likewise if I don't want you to see network sockets, why do I want to let=
=20
you see processes? If I let you see "httpd", well chances are something's=
=20
open on port 80, 8000, or 8080.

It strikes me as what Charles Hannum once described as a "Berkeley
abstraction." On a number of occasions, Berkeley added support for
abstractions when in fact only one instance of the abstraction would be
used. So we ended up supporting an abstraction we didn't need; we paid the
price of conditionals/vectoring or whatever but we got no benefit as we
always chose one path.

So my vote is go with one knob now and see what folks experience. If we
have folks who find they really want to let a user see one thing or the
other, then we can revisit.

Take care,

Bill

--yH1ZJFh+qWm+VodA
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDE3McWz+3JHUci9cRAtrSAJ9vTGOSrgVZeLtwwFk4gndjhGp6lwCgivY6
8CmtjyCXDk0hzLddLqJNZ3E=
=VmWu
-----END PGP SIGNATURE-----

--yH1ZJFh+qWm+VodA--