lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 00:01:07 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support

Andi Kleen <andi@...stfloor.org> writes:

>> can still use the  config option for the compatibility code.
>> There wouldn't even be a performance penalty over new glibc with
>> new kernels which already use procfs.
>
> When he drops the sysctl(2) API completely the old userland will
> be unhappy.

When it comes to breaking user space the issue is not glibc or
anything in a open source distribution.  There are maybe 3 apps that
are affected at all and as far as I can tell they were all fixed long
ago.  Last time I investigated this in 2007 none of the existing
userlands would break if sysctl was disabled completely.

The issue is all of the in-house and 3rd party software, that we don't
have access to.  We have no way of knowing what is used.  So I do not
favor a solution that kills some but not all sysctls.  Either you
might need them or you don't.

So the decision must be made to you break the rare app from the writer
who has given you no feed back after you have given him fair warning,
or do you try and support him forever, with code that no cares about
and no one tests.

I think the solution in sysctl_binary.c strikes a good balance there.
The code is simple and should survive a long time with little to no
maintenance, so it is good if we need decide we are too chicken to
disable the sysctl system call, and at the same time my changes remove
the support overhead from everywhere else.

Further with the existence of a single file for all of the binary
sysctls we can modify it to strike any other balance between long term
maintainability, and removal of unused cruft.

I am happy to see additional patches from anyone else who chooses to seek
a different balance.

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

Powered by blists - more mailing lists