Subject: Re: sysctl knob to let sugid processes dump core (pr 15994)
To: Curt Sampson <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 02/06/2006 13:59:38
Content-Type: text/plain; charset=us-ascii
On Fri, Feb 03, 2006 at 05:27:59PM +0900, Curt Sampson wrote:
> On Fri, 3 Feb 2006, YAMAMOTO Takashi wrote:
> >"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=
> 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=
dumping with the non-set-id core dumping; all the core dumping's together.=
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=
the best. It is in effect adding a second index to the hierarcy. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----