[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C8FDAEF.17347.14CA1791@pageexec.freemail.hu>
Date: Tue, 14 Sep 2010 22:28:31 +0200
From: pageexec@...email.hu
To: Roland McGrath <roland@...hat.com>
CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Brad Spengler <spender@...ecurity.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, oss-security@...ts.openwall.com,
Solar Designer <solar@...nwall.com>,
Kees Cook <kees.cook@...onical.com>,
Al Viro <viro@...iv.linux.org.uk>,
Oleg Nesterov <oleg@...hat.com>,
Neil Horman <nhorman@...driver.com>,
linux-fsdevel@...r.kernel.org, Eugene Teo <eugene@...hat.com>
Subject: Re: [PATCH 1/3] setup_arg_pages: diagnose excessive argument size
On 14 Sep 2010 at 11:51, Roland McGrath wrote:
> > no it doesn't have to, similarly to how it doesn't have to hardcode
> > _SC_PAGESIZE either, AT_PAGESZ tells userland what it needs to know
> > and i think AT_ARGMAX could exist just as well.
>
> I was referring to the ways available to userland heretofore. Certainly,
> the kernel could add new ways and then userland could do different things
> (with new kernels).
>
> auxv in particular is not a mechanism that could fit for this. The actual
> limit depends on rlimits of the calling process, and rlimits can change
> during the life of the program.
obviously an AT_ARGMAX computed at execve time would be based on the rlimits
as well and if later userland changed the rlimits, it'd be userland's problem,
not that of the kernel (or the kernel could refuse a change that would violate
its earlier promise).
> auxv is only appropriate for things that
> are known at the time of the exec and won't change thereafter.
you mean stuff like AT_EUID et al.? ;)
--
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