Re: Security issues with local filesystem caching

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

On Fri, 2006-11-03 at 10:27 +0000, David Howells wrote:

> Anyway, it's not just vfs_mkdir(), there's also vfs_create(), vfs_rename(),
> vfs_unlink(), vfs_setxattr(), vfs_getxattr(), and I'm going to need a
> vfs_lookup() or something (a pathwalk to next dentry).
> 
> Yes, I'd prefer not to have to use these, but that doesn't seem to be an
> option.

It is not as if we care about an extra context switch here, and we
really don't want to do that file i/o in the context of the rpciod
process if we can avoid it. It might be nice to be able to do those
calls that only involve lookup+read in the context of the user's process
in order to avoid the context switch when paging in data from the cache,
but writing to it both can and should be done as a write-behind process.

IOW: we should rather set up a separate workqueue to write data to disk,
and just concentrate on working out a way to lookup and read data with
no fsuid/fsgid changes and preferably a minimum of selinux magic.

> > > Also I should be setting security labels on the files I create.
> > 
> > To what end? These files shouldn't need to be made visible to userland
> > at all.
> 
> But they are visible to userland and they have to be visible to userland.  They
> exist in the filesystem in which the cache resides, and they need to be visible
> so that cachefilesd can do the culling work.  If you were thinking of using
> "deleted" files, remember that I want it to be persistent across reboots, or
> even when an NFS inode is flushed from memory to make space and then reloaded
> later.

No. I was thinking of keeping the cache on its own partition and using
kernel mounts. cachefilesd could possibly mount the thing in its own
private namespace.

Trond