From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: DoS with unprivileged mounts Date: Wed, 14 Aug 2013 13:25:34 -0700 Message-ID: References: <520BD9E0.8050304@mit.edu> <8761v882wj.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Miklos Szeredi , "Serge E. Hallyn" , Al Viro , Linux-Fsdevel , Kernel Mailing List To: "Eric W. Biederman" Return-path: Received: from mail-vc0-f182.google.com ([209.85.220.182]:39131 "EHLO mail-vc0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758395Ab3HNUZz (ORCPT ); Wed, 14 Aug 2013 16:25:55 -0400 Received: by mail-vc0-f182.google.com with SMTP id hf12so5612105vcb.13 for ; Wed, 14 Aug 2013 13:25:54 -0700 (PDT) In-Reply-To: <8761v882wj.fsf@xmission.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Aug 14, 2013 at 12:53 PM, Eric W. Biederman wrote: > Andy Lutomirski 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