Date: Thu, 21 May 2009 10:36:32 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Garrett Wollman <wollman@bimajority.org> Cc: arch@freebsd.org, Lothar Scholz <scholz@scriptolutions.com> Subject: Re: Posix shared memory problem Message-ID: <alpine.BSF.2.00.0905211033380.25537@fledge.watson.org> In-Reply-To: <18952.21468.748665.878710@hergotha.csail.mit.edu> References: <mit.lcs.mail.freebsd-arch/588815840.20090509203115@scriptolutions.com> <mit.lcs.mail.freebsd-arch/20090509200724.GA25714@stack.nl> <200905100500.n4A50GOa050728@hergotha.csail.mit.edu> <7710650619.20090510075706@scriptolutions.com> <18950.63671.323324.756287@hergotha.csail.mit.edu> <1393224851.20090511112537@scriptolutions.com> <18952.21468.748665.878710@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 May 2009, Garrett Wollman wrote: > <<On Mon, 11 May 2009 11:25:37 +0200, Lothar Scholz <scholz@scriptolutions.com> said: > >> Some idiots started to think about this as a file path. But it isn't >> and it shouldn't. > > Actually, it really should be. Ask a security person or a virtualization > person to explain why an unnecessary multiplicity of namespaces is a bad > idea. Despite having been partly responsible for the new POSIX shm code in 8.x that removes file system namespace use for POSIX shm, I strongly agree with your statement. The hierarchal and access-controlled structure of the file system namespace is a key feature that makes it preferable to the plethora of other weird global namespaces arriving with various new IPC models. A hierarchal namespace with access control allows reliable delegation of portions of the namespace -- for example, administrators can authorize a user to use any name in "/home/username" without worrying that users will spoof each others services based on application start order, crashes, etc. The existence of additional flat namespaces, such as used by System V IPC, POSIX shm, POSIX sem, etc, is quite problematic from this perspective, and significantly increases the risk of vulnerability. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0905211033380.25537>