Re: Security issues with local filesystem caching

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Fri, 2006-11-03 at 15:23 +0000, David Howells wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> 
> > It is not as if we care about an extra context switch here,
> 
> Avoiding context switches aren't the main problem; avoiding serialisation is.

Why? It is a backing cache. The only case where serialisation ought to
bother you is the case where the client has to invalidate the cache due
to a server-side update of the file.

> > and we really don't want to do that file i/o in the context of the rpciod
> > process if we can avoid it.
> 
> We aren't doing file I/O in the context of the rpciod process, at least not to
> the cache.  It's either done in the context of the process that issued the
> read, write or pagefault.

Once the RPC calls have been launched, the process returns to the VM
layer and just waits for the next page to be unlocked. It never returns
to the filesystem layer. So where are you using the process context to
write out the cached data?

> The security problems come from the lookups, creates, xattr ops that we have to
> do when acquiring a cookie.  All of these are done in the context of the
> process that called iget5 for NFS.  We could farm them out to another process
> to avoid the security, but that would then cause serialisation and context
> switches.

The cookie lookups need to be synchronous, but why would the file
creation need to be synchronous? Creating the cachefs file and waiting
on that to complete etc are all utterly useless activities as far as
satisfying the user request for data goes. Just start the process of
creating a backing file, and then get on with the actual syscall.

> Writing data to the cache is done by the pagecache at the moment.  I'd really
> like to use direct I/O instead as that'd mean I wouldn't need shadow pages in
> the page cache and I'd also be able to avoid the page-to-page copy I'm
> currently doing.

Agreed.

Trond