On Tue, 05 Feb 2002 14:01:06 EST, Antony Edwards <aedwardat_private> said: > data from the disk without going through filemap_nopage. Saying that > the module has to revoke all pages containing data from the file > from the page table is equivalent to saying that the module has to > go and clear any user buffers that were passed to read(2). Agreed - and of course, the *big* problem is that once filemap_nopage has read it in and it's been in the shared memory segment, you have to assume it's been copied out of it into some arbitrary userspace databuffer. > MMAP_SHARED obviously changes this -- but to me the new aspects are > shared memory semantics, and the existing protection is the same as > that for normal shared memory. Given 2 processes that both open a file 'foo', and then use that fd to open an MMAP_SHARED, what happens if one process gets the fd revoked? (For that matter, in the I-havent-tried category, if you mmap() and then close() that fd, does the mmap() persist and Do What You Expect?) The other process could then still "tunnel" information out. Of course, that's just a specific of the general problem of two processes in distinct security domains passing data over a connection (be it TCP, a semaphore, unix-domain sockets, a named pipe, or even a shared file..) /Valdis
This archive was generated by hypermail 2b30 : Tue Feb 05 2002 - 11:40:36 PST