On Tue, 22 Mar 2011, Al Viro wrote: > On Tue, Mar 22, 2011 at 07:58:17PM +0100, Miklos Szeredi wrote: > > > > > and its protection against renames is > > > > nowhere near enough. ??I might be missing something subtle, but... > > > > Protection is exactly as for userspace callers. AFAICT. > > BTW, what filesystems can act as upper layers and how are you going to > prevent modifications of upper layer in normal way? It is mounted, > after all, or you would be unable to find it when mounting overlayfs. > And it might be mounted in any number of places, not all even visible to > you... I realize that you have it listed as a problem, but do you have > any ideas on how to deal with that? Yes, I have some patches, but decided that that should be a separate set, once the basics are ironed out. Since the locking guarantees are separated on the upper/lower fs from the overlayfs, allowing modification is not a huge problem. The worst that can happen is that an attacker who has access to both the overlay and the upper or lower fs then can "build" an arbitrarily deep directory tree on the overlayfs. Not a big issue. There won't be deadlocks or filesystem corruption. > If you allow NFS as upper layer, you really have a problem; with this > approach you probably want to prevent that very forcibly. Not that > your open() handling would work correctly with NFS, even with no modifications > from other clients or from server... Upper layer doesn't work on NFS for multiple reasons. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
