On Wed, Aug 14, 2013 at 12:53 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > >> On 08/14/2013 10:42 AM, Miklos Szeredi wrote: >>> There's a simple and effective way to prevent unlink(2) and rename(2) >>> from operating on any file or directory by simply mounting something >>> on it. In any mount instance in any namespace. >>> >>> Was this considered in the unprivileged mount design? >>> >>> The solution is also theoretically simple: mounts in unpriv namespaces >>> are marked "volatile" and are dissolved on an unlink type operation. >> >> I'd actually prefer the reverse: unprivileged mounts don't prevent >> unlink and rename. If the dentry goes away, then the mount could still >> exist, sans underlying file. (This is already supported on network >> filesystems.) > > Of course we do this in network filesystems by pretending the > rename/unlink did not actually happen. The vfs insists that it be lied > to instead of mirroring what actually happened. > > Again all of this is a question about efficient data structures and not > really one of semantics. Can either semantic be implemented in such a > way that it does not slow down the vfs? Given that vfs_unlink has: if (d_mountpoint(dentry)) error = -EBUSY; I think it's just a matter of changing / deleting that code. --Andy -- 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
