linux-kernel - Re: [PATCH] Support single byte reads from integers published in procfs by kernel/sysctl.c

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 linux-cve-announce 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]

Message-ID: <4F1D8180.9030509@ixiacom.com>
Date:	Mon, 23 Jan 2012 07:49:20 -0800
From:	Earl Chew <echew@...acom.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge.hallyn@...onical.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<adobriyan@...il.com>
Subject: Re: [PATCH] Support single byte reads from integers published in
 procfs by kernel/sysctl.c

On 23/01/2012 6:47 AM, Eric W. Biederman wrote:
> The difference between strings and integers is that with strings
> single byte reads/writes actually make sense.
> 
> Single decimal digits reads don't make much sense at all for integers.
> 
> Is there any compelling reason to support this complete idiocy from user
> space programs?

Eric,

[ I also note that the patch allows multiple short reads (not necessarily
  just a single byte at a time) from these entries in procfs. ]

I think there is a reasonable userspace expectation that entities
that present themselves as text files to produce results that are
consistent with the userspace model of a text file.

For a more concrete example, consider the following BusyBox ash(1) code:

read X < /proc/sys/kernel/threads-max
Y=$(cat /proc/sys/kernel/threads-max)

read A < /proc/sys/kernel/core_pattern
B=$(cat /proc/sys/kernel/core_pattern)

The fact that these yield different results is surprising given that
the user sees these as text files.

I think it is worthwhile asking the opposite question,

" Is there any compelling reason for the kernel to require userspace
  programs to access /proc/sys/kernel/threads-max any differently
  from, say, /etc/fstab ? "

If the answer is in the affirmative, then it requires some layer in
the userspace program (presumably the IO layer) to make some
special accommodation for some entries in /proc.

As can be seen in the case of BusyBox, this approach might be difficult
to swallow in something as generic as ash(1), so it is left to the user to
puzzle out why read fails, but cat works -- but only sometimes.

Earl

--
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/