Date: Sun, 26 Aug 2001 09:47:16 +0300 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mmap MAP_INHERIT question. Message-ID: <20010826094715.A845@iv.nn.kiev.ua> In-Reply-To: <200108241611.f7OGBok95888@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Aug 24, 2001 at 09:11:50AM -0700 References: <Pine.BSF.4.21.0108231012330.48732-100000@InterJet.elischer.org> <200108231738.f7NHcVo87785@earth.backplane.com> <20010823223315.B2991@hades.hell.gr> <20010823125905.L63814@nexus.root.com> <200108241611.f7OGBok95888@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010826094715.A845>