[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706071438020.6445@alien.or.mcafeemobile.com>
Date: Thu, 7 Jun 2007 14:44:21 -0700 (PDT)
From: Davide Libenzi <davidel@...ilserver.org>
To: Ulrich Drepper <drepper@...hat.com>
cc: Eric Dumazet <dada1@...mosbay.com>,
Kyle Moffett <mrmacman_g4@....com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Thu, 7 Jun 2007, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric Dumazet wrote:
> > I am afraid randomization wont really work if /sbin/init or /bin/bash
> > for example uses one (or more) unseq fd :
> > The 'random base' will be propagated at fork()/exec() time ?
>
> The base certainly should be reset o fork. Yes, this might expand the
> region in which descriptors are allocated due to inherited descriptors.
> But I consider this the application's problem and it usually is not
> really an issue. Apps have to explicitly request using the new
> descriptors and they can use CLOEXEC (CLOFORK) correctly.
This is kinda fishy. We'll end up with very large map with lots of
unused space in them.
What we can sanily do, is re-random the base if no fds are in there (of
course CLOFORK and CLOEXEC do not count).
- Davide
-
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