Messages in this thread | | | Date | Thu, 22 Jun 2006 19:24:03 -0600 | From | Robert Hancock <> | Subject | Re: make PROT_WRITE imply PROT_READ |
| |
Jason Baron wrote: > Currently, if i mmap() a file PROT_WRITE only and then first read from it > and then write to it, i get a SEGV. However, if i write to it first and > then read from it, i get no SEGV. This seems rather inconsistent. > > The current implementation seems to be to make PROT_WRITE imply PROT_READ, > however it does not quite work correctly. The patch below resolves this > issue, by explicitly setting the PROT_READ flag when PROT_WRITE is > requested.
I would disagree.. the kernel is enforcing the permissions specified where the CPU architecture allows it. There is no sense in breaking this everywhere just because we can't always enforce it. By that logic we should be making PROT_READ imply PROT_EXEC because not all CPUs can enforce them separately, which makes no sense at all.
> > This might appear at first as a possible permissions subversion, as i > could get PROT_READ on a file that i only have write permission > to...however, the mmap implementation requires that the file be opened > with at least read access already. Thus, i don't believe there is any > issue with regards to permissions. > > Another consequenece of this patch is that it forces PROT_READ even for > architectures that might be able to support it, (I know that x86, x86_64 > and ia64 do not) but i think this is best for portability.
That makes little sense to me.. if you want portability, and you're reading from the file, you better request PROT_READ. Any app that doesn't do that is inherently broken and non-portable regardless of what you do to the kernel.
-- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |