From owner-freebsd-hackers Mon Feb 28 13: 6: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D0F9137B949 for ; Mon, 28 Feb 2000 13:06:00 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id NAA10474; Mon, 28 Feb 2000 13:36:08 -0800 (PST) Date: Mon, 28 Feb 2000 13:36:08 -0800 From: Alfred Perlstein To: Brooks Davis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mprotect(2) won't make shared memory read-only Message-ID: <20000228133608.T21720@fw.wintelcom.net> References: <20000228125013.A25992@orion.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000228125013.A25992@orion.ac.hmc.edu>; from brooks@one-eyed-alien.net on Mon, Feb 28, 2000 at 12:50:13PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brooks Davis [000228 13:23] wrote: > On a -current system as of a week or two ago (as well as a 3.3-RC and a > 2.2.8-STABLE box) I've found that mprotect fails with with EACCES when > trying to make a shared memory segment that was created user read/write > read-only. It works find if I malloc the memory instead and making the > shm segment write-only or inaccessible works fine as well. Is this > expected behavior? If so it's pretty weird. If you can point out any standards documents that mandate this behavior (i'm not saying there isn't any, but I'm unaware of it) or a list of OSs that support it, it would motivate action. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message