Allow mmap operations for CAPH_READ and CAPH_WRITE.

[delphij]

Summary

Allow mmap operations for CAPH_READ and CAPH_WRITE on streams.

[oshogbo]

Is this some common pattern?

[delphij]

In D18920#405658, @oshogbo wrote:

Is this some common pattern?

Yes, this was actually exposed by rS343117 where a later restriction was performed on the same stdin stream that would have allowed mmap'ed operations. While stdin itself doesn't really allow mmap, for the more generic file operation case, because we already allowed CAP_SEEK, it seems to be reasonable to just allow mmap'ed operation at the same time.

[markj]

In D18920#405771, @delphij wrote:

In D18920#405658, @oshogbo wrote:

Is this some common pattern?

Yes, this was actually exposed by rS343117 where a later restriction was performed on the same stdin stream that would have allowed mmap'ed operations. While stdin itself doesn't really allow mmap, for the more generic file operation case, because we already allowed CAP_SEEK, it seems to be reasonable to just allow mmap'ed operation at the same time.

Sorry for the delay, I did not see the initial email for this review.

As we discussed in email, I don't really like this because it's extraneous to the API. It lets us fix cmp(1), but only because cmp(1) happens to use mmap() for regular files instead of the stream abstraction. CAP_MMAP_* lets one play games with the VM, you can do things like replace an existing mapping or very quickly dirty pages.

cmp(1) should really use separate sets of rights for the special (streams) and !special (mmap) cases. It is a bit tricky because the !special case will fall back to using streams if mmap() fails. I'm not yet sure how best to deal with this.

I won't block this patch, but I think it's the wrong direction.

[markj]

Sorry for taking a while to get back to this. I have an alternate patch at D19216.

[delphij]

Abandoned in favor of D19216.