From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933161Ab3HNT0b (ORCPT ); Wed, 14 Aug 2013 15:26:31 -0400 Received: from mail-pb0-f47.google.com ([209.85.160.47]:63534 "EHLO mail-pb0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933107Ab3HNT01 (ORCPT ); Wed, 14 Aug 2013 15:26:27 -0400 Message-ID: <520BD9E0.8050304@mit.edu> Date: Wed, 14 Aug 2013 12:26:24 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Miklos Szeredi CC: "Eric W. Biederman" , "Serge E. Hallyn" , Al Viro , Linux-Fsdevel , Kernel Mailing List Subject: Re: DoS with unprivileged mounts References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.) --Andy