Re: Security issues with local filesystem caching

[David Howells]

Josef Sipek <jsipek@xxxxxxxxxxxxxxxxx> wrote:

> Hrm. How do you do DAC checks if you don't copy over the permissions without
> alteration?

You have to remember there are two filesystem layers involved.  NFS or other
netfs does the DAC, MAC, whatever checks to see whether the user can access a
file.  NFS then asks the cache to back the netfs file and the cache creates a
file in the local filesystem to do that.

The cache file doesn't need the DAC/MAC/whatever attributes applied to the
netfs file, and, in fact, may not be able to support what the netfs deals
with.

> I'm wondering, why don't just you duplicate all the attributes of the files
> (including xattrs)? That would take care of most if not all the DAC/MAC
> issues, no?

You're forgetting that the userspace cache manager daemon still has to access
the cache.

> >  (1) Do all the cache operations in their own thread (sort of like knfsd).
>  
> In our case it works well, however we have only very specific times when we
> need to use the work queue, so the performance hit doesn't hurt us as much
> as it would hurt you - I'm assuming you'd be using the thread for a sizable
> portion of calls you get.

I'm not sure exactly.  Actually, I could probably deal with read/write ops
inline - though I don't have a file struct to carry a security context - but
getting and releasing inodes would certainly wind up being farmed off.
Consider the automounter releasing an NFS share that's been heavily used...

> I'm thinking that it would be nice to combine the caching related security
> code with those for stackable filesystems.

That's fine by me, though I want the security on a cache file to be different
to that on the netfs file it's backing.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/