From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Subject: Re: [PATCH v8 2/2] overlayfs: override_creds=off option bypass creator_cred Date: Wed, 14 Nov 2018 17:00:21 -0500 Message-ID: <20181114220021.GD29804@redhat.com> References: <20181106230117.127616-1-salyzyn@android.com> <20181106230117.127616-2-salyzyn@android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20181106230117.127616-2-salyzyn@android.com> Sender: linux-kernel-owner@vger.kernel.org To: Mark Salyzyn Cc: linux-kernel@vger.kernel.org, Miklos Szeredi , Jonathan Corbet , "Eric W . Biederman" , Amir Goldstein , Randy Dunlap , Stephen Smalley , linux-unionfs@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@android.com List-Id: linux-unionfs@vger.kernel.org On Tue, Nov 06, 2018 at 03:01:15PM -0800, Mark Salyzyn wrote: > By default, all access to the upper, lower and work directories is the > recorded mounter's MAC and DAC credentials. The incoming accesses are > checked against the caller's credentials. Some random things. Not sure what's the correct answer. It might not even be a issue, just trying to think loud. - ovl_permission() does not do the check for permission on underlying inode if only MAY_EXEC is being asked for. This kind of sounds like a problem. That means one can create an overlay mount with context= and allow a process to execute a file which it could not execute outside overlay mount. If this is an issue, it probably is an issue both with override_creds=on/off. - ovl_permission() does not check for permission on underlying inode for special file. Is it a problem where one can not do an operation on special device on host but can do it through overlay context mount. - What about creds for copy up. ovl_prep_cu_creds(). Looks like even with override_creds=off, we will be switching to the creds as returned by security_inode_copy_up(). This basically sets ->create_sid if it is a context mount so that new inode gets created with same label as context=