Nathan J. Williams wrote:

> The same reason; I don't like sysctl being used for things other than
> individual knobs. I'm OK with sysctl(8) as a UI, but I don't think
> that sysctl(3) does much but duplicate other infrastructure - namely,
> the filesystem.

I understand your point, though let me point out some things:

1. This is *your* view of sysctl(3);
2. Removing a sgid kmem binary *NOW* is better than "coming up with a
   better solution in the future";
3. How many locally exploitable root holes procfs (on BSD/Linux) and/or
   kernfs have? how many our sysctl(9) have?

I believe it is wrong to nuke changes that are positive to the current
reality with the reason that "IF we do something else in the future
we'll have to change the code again".

-e.

-- 
Elad Efrat