Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check.
(Except I didn't say that here. Oops. Getting confused with my posts.)
But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't make sense to limit splice such that it can't do the task it was built for. Maybe splice should just not write to the input fd? :P
Not really, splice(2) is actually more limited, it's an optimisation for reading and writing data between files and pipes without needing to make copies.
sendfile(2) works with any fds because it just exists to remove a fair bit of the copy overhead when doing a userspace read/write loop, but it does actually do a copy.
But apparently we can't be trusted with the page cache…
Maybe the kernel using supervisor-read-only flags could be made to work, only issue then is what happens if something does in fact need to write…