linux-kernel - Re: [Patch] sysctl: forbid too long numbers

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: <75b66ecd0907011922x1843c0d3g9c3bf6f686f981e2@mail.gmail.com>
Date:	Wed, 1 Jul 2009 22:22:45 -0400
From:	Lee Revell <rlrevell@...-job.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Amerigo Wang <amwang@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [Patch] sysctl: forbid too long numbers

On Mon, Jun 29, 2009 at 6:01 PM, Andrew Morton<akpm@...ux-foundation.org> wrote:
> Or are they?  One could imagine a script which was tested and developed
> on a 64-bit system, which writes a >4G number into a pseudo file.  That
> script happens to work on 32-bit systems (it might not work _well_, but
> it'll work).  With this change, the write will fail on the 32-bit
> system and the entire application could bale out or something.
>
> I'm not saying that this is a reason to avoid making the change, but
> it's all a worry and needs consideration.

This would break at least one existing setup that I know of.  Consider
an environment where shmmax is set to the value the biggest server
needs (well over 4GB) on all database servers to simplify management.
This change would cause the database to fail on the old 32 bit servers
used for testing and QA.

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