Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2942660imm; Thu, 24 May 2018 19:34:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrzIyCB1yQlSDRP8W3dualGoLSg5zRtbyNILBe3hDMdDdjWOoXNcGeRNCTCxWTtkInX2DUP X-Received: by 2002:a62:aa18:: with SMTP id e24-v6mr551618pff.107.1527215643041; Thu, 24 May 2018 19:34:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527215643; cv=none; d=google.com; s=arc-20160816; b=r+PgrCvj8QZHjWs4KpxVyszlX7beuQcNNryfCSkKZl/Fsk3Hevw74b3Re3yxCMdtvc XwGHwRo9KeDXc6a9iowbc4QAU4T2ArxB20HdNCMcBqE5IxRs9Kf5ca0i8LPGyfJAn/MK vx2+8PUWysscyrtjg9YOJnWmlKaUHDN9Pzmq6mIEyoroSMoAOczziogyjWCtqz8U7suh kqjLG/mzzrzVhM/x3jj82yBFn62d+jjtxyBhyJl7ueVYb7ITDhLoNqLAdgISLo7I6Mzm gm7ixgwr9yK8Ok2r+lOhWgl529nnQ/K9sAdyl8hEXTAT0q/JUAsxSJTK8Fi4rgytbpg+ xC2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=d51YTbpWxJVLOW0mtDZRGpW6RfNixy72iyM1hyHpLto=; b=Vn9flnB1GjuDfaBONW+yVZaFYlXFgzZoMJfTevxCLotNbpWpPwCCLshNiLlAKWPRdp e9YmdLXh1MtBCwUYswXoZWJOKyfrJHId6KfrDHRI1zZ+/iIf7nqJrK87Q2U/t2qwiF3o WefD5lkhSlh6qprLEFnnJR4qgUCDd9I8SwLADXKdHx8Jwz5qyx5PFJIwpAQ6wRazdORA 9nD6YairKJR8MZOA5NBAJGVdhToQVfBwwPhoid0U93rSnBP/sYEOmCexoK4z9uBV8l05 DkCCBDonZB/7huWtq7zQgpAO0bG37rNnZ5m/e/Whg7SZTTs7Lw+OhWs9aMnIpIHkSI0+ O1Tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14-v6si4528126pgz.284.2018.05.24.19.33.48; Thu, 24 May 2018 19:34:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034163AbeEXRWj (ORCPT + 99 others); Thu, 24 May 2018 13:22:39 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:53690 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031084AbeEXRWg (ORCPT ); Thu, 24 May 2018 13:22:36 -0400 Received: from mail-io0-f198.google.com ([209.85.223.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fLtwh-0008Na-Pn for linux-kernel@vger.kernel.org; Thu, 24 May 2018 17:22:35 +0000 Received: by mail-io0-f198.google.com with SMTP id u23-v6so2102157ioc.13 for ; Thu, 24 May 2018 10:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=d51YTbpWxJVLOW0mtDZRGpW6RfNixy72iyM1hyHpLto=; b=Rupm7cUwGyU3g4cDxPpOqnL89v48jsysoTx6YKFsiGjSa1pDZKMSw8P97Kly9BuTWj AVgqe5ViIct7xMEB7PI81R1GFk1G+S8rZYXRtE13QIffAClkZDbom7ozPpV/3mJBcbgg 0UfzO+zSrMxlVl/ccYvoxsn9yZTFLaDDr7VneEfSX9toTna3FHkTwjjNY2DOz8qFCgJG hsGKNx8+srdm+CHvMgVoQHMaQK2+AsaTlLNSbAYX1oLvp7Prs3mO0/FFgRbnzTJIJwjY xLh6OrpJJWBIRnHMvUYpdk/aB0yazL82ie7e/Y0jcC7jPXxB/DYLZ3KABO2ia6IFilMh LEAQ== X-Gm-Message-State: ALKqPweUDu4B2wcYnmfrpNAdYoiLNGDP012TIiMcp2CJfJa96LBe1IF8 hBkr75RgEVjc/Ssq1Oh6eFPBpesX93OAVtn7cqTzAlS/e2D1/1CiXaEw0MxVY/R+lD1pv7T3f77 VJv8k3wwOputwj9MF5qxJlzWNC4w4+x8wANN99TQcaw== X-Received: by 2002:a6b:dc1a:: with SMTP id s26-v6mr7941596ioc.157.1527182554734; Thu, 24 May 2018 10:22:34 -0700 (PDT) X-Received: by 2002:a6b:dc1a:: with SMTP id s26-v6mr7941578ioc.157.1527182554462; Thu, 24 May 2018 10:22:34 -0700 (PDT) Received: from localhost ([2605:a601:ac6:7f20:64ef:8fb:fbce:66ef]) by smtp.gmail.com with ESMTPSA id s10-v6sm11358314ioc.84.2018.05.24.10.22.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 24 May 2018 10:22:33 -0700 (PDT) Date: Thu, 24 May 2018 12:22:32 -0500 From: Seth Forshee To: "Eric W. Biederman" Cc: Linux Containers , linux-fsdevel@vger.kernel.org, "Serge E. Hallyn" , Christian Brauner , linux-kernel@vger.kernel.org Subject: Re: [REVIEW][PATCH 2/6] vfs: Allow userns root to call mknod on owned filesystems. Message-ID: <20180524172232.GS3401@ubuntu-xps13> References: <87o9h6554f.fsf@xmission.com> <20180523232538.4880-2-ebiederm@xmission.com> <20180524135517.GQ3401@ubuntu-xps13> <87y3g92dta.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y3g92dta.fsf@xmission.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 11:55:45AM -0500, Eric W. Biederman wrote: > Seth Forshee writes: > > > On Wed, May 23, 2018 at 06:25:34PM -0500, Eric W. Biederman wrote: > >> These filesystems already always set SB_I_NODEV so mknod will not be > >> useful for gaining control of any devices no matter their permissions. > >> This will allow overlayfs and applications to fakeroot to use device > >> nodes to represent things on disk. > >> > >> Signed-off-by: "Eric W. Biederman" > > > > For a normal filesystem this does seem safe enough. > > > > However, I'd also like to see us allow unprivileged mounting for > > overlayfs, and there we need to worry about whether this would allow a > > mknod in an underlying filesystem which should not be allowed. That > > mknod will be subject to this same check in the underlying filesystem > > using the credentials of the user that mounted the overaly fs, which > > should be sufficient to ensure that the mknod is permitted. > > Sufficient to ensure the mknod is not permitted on the underlying > filesystem. I believe you mean. Right, or in other words with the relaxed capability check a user still could not use an overlayfs mount in a user namespace to mknod in a filesystem when that user couldn't otherwise mknod in that filesystem. Sorry if I wasn't clear. > > > Thus this looks okay to me. > > > > Acked-by: Seth Forshee > > Eric >