>> I'm not sure there's more here than a covert channel [...]
> We should check, but I doubt there is a security issue here.

Depends on what you consider a security issue.

> All you're going to find is anything extra you scribbled while the
> page was in cache.

No...anything extra *someone* scribbled while the page was in cache.
Hence my calling it a covert channel: it's something processes can use
to communicate while appearing to be not communicating - that is, the
channel is hard to detect (because it never makes it to the file) or
trace (because it's lost as soon as that page is tossed from cache).

Admittedly, this isn't quite the usual use of the term "covert
channel"; it more usually refers to a method for two entities to
communicate that aren't supposed to be able to communicate.  But I
think communicating without appearing to use any channel they have
(such as a mutually writable file) is close enough that I don't mind
using the term.

This is a security issue in a sufficiently paranoid context.  Is NetBSD
such a context?  That's the debatable part.  I suspect it is not - we
have so many other covert channels - but I'd still prefer to see the
bug fixed.  (Probably not enough to actually do the work myself, so I'm
not sure attention should be paid to my preferences, of course.)

> The one issue we would need to keep track of in "fixing" this issue
> is that we don't clobber something that's in the process of extending
> the file.

Hmm, that's a good question.

Process A:
	open 10-byte file
	mmap 10 bytes
Process B:
	extend file to 20 bytes
Process A:
	write into the 10-20 byte range of the mapping

Should the data process A writes make it into the file?  I'd say it
shouldn't in an abstract sense, but that could be very hard to arrange,
especially if you want modifications to the 0-10 range to be shared.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B