--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 03, 2006 at 05:27:59PM +0900, Curt Sampson wrote:
> On Fri, 3 Feb 2006, YAMAMOTO Takashi wrote:
>=20
> >"security" node doesn't seem to fit to the way how the rest of tree is
> >currently organized.
> >do you want to create "performance" top level node, which collects
> >performance related knobs?  to me, "security" node seems something like=
=20
> >that.
>=20
> No, I think a "performance" node would be a bad idea. But security is
> special, because it's so important. That said, I'm not sure it really
> needs a separate node; I'd need to examine all the security-related
> settings in context to see.

My concern with such an idea would be that you're assuming that the=20
administrator primarily thinks about the parameter as a "security" one.=20
If it's thought of as a security attribute of something else, puting it=20
under "security" can make it harder to find.

Ok, that didn't come out well. Taking an example from this thread, say I=20
think of set-id core dumps as a special case of core dumps. If=20
everything's under kern. or kern.core., then I can easily find set-id core=
=20
dumping with the non-set-id core dumping; all the core dumping's together.=
=20
If we factor it all out, then it can get hard to find.

I think the suggestion of a file listing of "security" sysctls is probably=
=20
the best. It is in effect adding a second index to the hierarcy. :-)

Take care,

Bill

--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFD58bKWz+3JHUci9cRAkA5AJ0Zk4xPFjj02RfesaCHZrfD9G5S4gCeIgrc
CRVmIsWUMO8dS/AK9ey2ydE=
=u1Z1
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--