From owner-freebsd-hackers Sat Aug 25 23:49:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by hub.freebsd.org (Postfix) with ESMTP id 6390937B410 for ; Sat, 25 Aug 2001 23:49:26 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id JSX04211; Sun, 26 Aug 2001 09:49:07 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.11.5/8.11.5) id f7Q6lGC01044; Sun, 26 Aug 2001 09:47:16 +0300 (EEST) (envelope-from netch) Date: Sun, 26 Aug 2001 09:47:16 +0300 From: Valentin Nechayev To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mmap MAP_INHERIT question. Message-ID: <20010826094715.A845@iv.nn.kiev.ua> References: <200108231738.f7NHcVo87785@earth.backplane.com> <20010823223315.B2991@hades.hell.gr> <20010823125905.L63814@nexus.root.com> <200108241611.f7OGBok95888@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200108241611.f7OGBok95888@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Aug 24, 2001 at 09:11:50AM -0700 X-42: On Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Fri, Aug 24, 2001 at 09:11:50, dillon (Matt Dillon) wrote about "Re: mmap MAP_INHERIT question.": > :> MAP_INHERIT This is supposed to permit regions to be > :> inherited across execve(2) system calls, > :> but is currently broken. > Yah, I agree. Even if we implemented it it would be a massive security > hole. a MAP_SHARED mmap() is easier. This is not bigger hole than passing uncontrolled file descriptors to sugid program (causing, e.g., getpwent() returning NULL without proper error reporting), or too low resource limits, causing program with bad coding style to fall into unprovided state. This is not bigger hole than the whole fork/exec concept, which ideologically allows uncontrolled state & environment features to affect the new process and its descendants in unpredictable way. As another example, let's consider ITIMER_REAL timer sent to sugid program which doesn't use timers, with unmasked signal, causing the victim to die when it is not allowed (e.g. some base in rebuilding). An inherited memory mapping will be rather safe inhabitant of this insanity. /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message