Re: [PATCH] sysctl: Deprecate sys_sysctl in a user space visible fashion.

[ebiederm@xmission.com (Eric W. Biederman)]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>>
>> My hypothesis.  No one cares now.
>>
>> My observation. The way we have been maintaining the binary sysctl
>> side of things using it is asking for your application to be broken in
>> subtle and nasty ways.
>>
>
> I suspect the right thing to do is simply to make a list of the supported binary
> sysctls, and automatically verify those numbers.  Doing that would alleviate
> these concerns, wouldn't break anything, and isn't really that hard to do.

Well the list is currently 1200 lines long, with wild cards in it.
See sysctl_check.c in the -mm tree.  I think I have finally found
all of the binary sysctl numbers that are currently in use but I may
have missed something.  Although that can probably be trimmed a bit
now that a number of those sysctls have been identified as impossibly
and always broken

The real problem is that sysctl uses different functions for the
binary path and the proc path.  Those functions return the same
data in two different forms.  When those functions diverge we
have problems.  As I recently found with about 42 of the netfilter
sysctls.

The concern is that no one uses these things so no one tests these
things, and no one complains about these things so the code bit rots.
When the code bit rots we can return the wrong value or set the
wrong value in the kernel or skip locking or skip permission checks
or various other nasty things.

Hmm.  Thinking about it I guess so far I have found about 10% of
the binary sysctls to have actual implementation problems.  Not my
idea of well maintained code.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/