Date: Tue, 13 Apr 2004 22:23:12 -0700 From: "David G. Lawrence" <dg@dglawrence.com> To: "Mark W. Krentel" <krentel@dreamscape.com> Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/64573: mmap with PROT_NONE, but still could be read Message-ID: <20040414052312.GB2439@nexus.dglawrence.com> In-Reply-To: <200404140441.i3E4fNaK038974@blue.mwk.domain> References: <20040414034342.GA2439@nexus.dglawrence.com> <200404140441.i3E4fNaK038974@blue.mwk.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Why would anyone want to mmap a file with PROT_NONE? > > The same reason you're allowed to create a file with mode 000. The > OS doesn't make value judgements about your program. If you ask for > PROT_NONE, then you're supposed to get PROT_NONE. That's a pretty weak argument. Files with mode 000 are still readable by root and the mode can be changed later to make the file more useful. You can't really say the same thing about mmap PROT_NONE. The reason I'm asking the question isn't because I'm trying to be a PITA. I'm asking this because it helps determine if the bug is in the kernel or if the bug is in the documentation. PROT_NONE (actually VM_PROT_NONE) is a protection that is used internally in the kernel for removing mappings from address spaces. The fact that it is exported as part of the mmap syscall API seems more than a little weird to me. I suspect that it is there for use with the mprotect() syscall (which is obviously useful), and not for mmap(). I don't know what the relavent standards specifications say about mmap() protections. If PROT_NONE is defined for use with mmap() and it is required that it make an unuseful mapping, then I'd be all for your suggested changes in order to be standards compliant. > The same bug happens mmap()-ing a file with PROT_WRITE, you still get > read access. In this case, PROT_NONE was just the simplest way to > demonstrate the bug. Actually that's a different case since many architectures don't support write-only regions, so a PROT_WRITE mapping implies PROT_READ in those cases. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040414052312.GB2439>