Date: Mon, 28 Feb 2000 13:27:17 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Alfred Perlstein <bright@wintelcom.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mprotect(2) won't make shared memory read-only Message-ID: <20000228132717.A13423@orion.ac.hmc.edu> In-Reply-To: <20000228133608.T21720@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Feb 28, 2000 at 01:36:08PM -0800 References: <20000228125013.A25992@orion.ac.hmc.edu> <20000228133608.T21720@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 28, 2000 at 01:36:08PM -0800, Alfred Perlstein wrote: > * Brooks Davis <brooks@one-eyed-alien.net> [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. I've verified that it workes as expected on Solaris 2.6, Irix 6.4, and some sort of RedHat with at 2.2.5-22 kernel (what I had immediate access to). I can't quote a standards document though. The thing that really got me was that I can take away all access, but I can't take away just and exec write access. That's more then a little bizarre. Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. 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?20000228132717.A13423>