Re: make PROT_WRITE imply PROT_READ

[Robert Hancock]

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@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/