Re: overlayfs access checks on underlying layers

2018-12-05 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote: > On 12/4/18 11:17 AM, Vivek Goyal wrote: > > On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: > > > On 12/4/18 10:42 AM, Vivek Goyal wrote: > > > > On Tue, Dec 04, 2018 at 04:31:09

Re: overlayfs access checks on underlying layers

2018-12-04 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: > On 12/4/18 10:42 AM, Vivek Goyal wrote: > > On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: > > > On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: > > > > > > > Having said

Re: overlayfs access checks on underlying layers

2018-12-04 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 10:42:35AM -0500, Stephen Smalley wrote: [..] > > > Yes, in that case there isn't an escalation of privilege for the mounter > > > (I > > > acknowledged that above). I'm still not sure copy-up of special files is > > > a > > > good idea though: > > > > > > - In the

Re: overlayfs access checks on underlying layers

2018-12-04 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: > On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: > > > Having said that, this still create little anomaly when mknod to client > > is not allowed on context label. So a device file, which is on lower > >

Re: overlayfs access checks on underlying layers

2018-12-04 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 10:15:49AM -0500, Vivek Goyal wrote: > On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote: > > On 12/4/18 8:32 AM, Miklos Szeredi wrote: > > > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley > > > wrote: > > > > >

Re: overlayfs access checks on underlying layers

2018-12-04 Thread Vivek Goyal
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote: > On 12/4/18 8:32 AM, Miklos Szeredi wrote: > > On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote: > > > > > > On 11/29/18 4:03 PM, Stephen Smalley wrote: > > > > On 11/29/18 2:47 PM, Miklos Szeredi wrote: > > > > > On Thu,

Re: overlayfs access checks on underlying layers

2018-11-29 Thread Vivek Goyal
On Thu, Nov 29, 2018 at 12:04:20PM +0100, Miklos Szeredi wrote: > On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote: > > > > On 11/28/18 3:24 PM, Miklos Szeredi wrote: > > > On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley > > > wrote: > > [...] > > > >> Does the breaking commit

Re: overlayfs access checks on underlying layers

2018-11-28 Thread Vivek Goyal
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote: > On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote: > > > > On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote: > > > [resending with fixed email address for Paul Moore] > > > >

Re: overlayfs access checks on underlying layers

2018-11-27 Thread Vivek Goyal
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote: > [resending with fixed email address for Paul Moore] > > Moving discussion from github[1] to here. > > To summarize: commit 007ea44892e6 ("ovl: relax permission checking on > underlying layers") was added in 4.20-rc1 to make

Re: [PATCH v8 2/2] overlayfs: override_creds=off option bypass creator_cred

2018-11-08 Thread Vivek Goyal
e the content have a different set of MAC > privileges (eg: read, for vendor labelled configuration, execute for > vendor libraries and modules). > > Signed-off-by: Mark Salyzyn > Cc: Miklos Szeredi > Cc: Jonathan Corbet > Cc: Vivek Goyal > Cc: Eric W. Biederman > C

Re: [PATCH] utimensat: AT_EMPTY_PATH support

2018-11-07 Thread Vivek Goyal
On Wed, Nov 07, 2018 at 10:15:52AM +0100, Miklos Szeredi wrote: > This makes it possible to use utimensat on an O_PATH file (including > symlinks). > > It supersedes the nonstandard utimensat(fd, NULL, ...) form. > > Signed-off-by: Miklos Szeredi Thanks for fixing this Miklos. It seems to work

Re: [PATCH 2/2] [FIXED v2] Replace magic for trusting the secondary keyring with #define

2018-08-16 Thread Vivek Goyal
On Thu, Aug 16, 2018 at 09:11:06AM +0800, Dave Young wrote: > On 08/16/18 at 12:07am, Yannik Sembritzki wrote: > > Signed-off-by: Yannik Sembritzki > > --- > >  arch/x86/kernel/kexec-bzimage64.c   | 2 +- > >  certs/system_keyring.c  | 3 ++- > >  

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread Vivek Goyal
On Wed, Aug 15, 2018 at 11:31:27PM +0200, Yannik Sembritzki wrote: > On 15.08.2018 23:13, James Bottomley wrote: > > Consider a UEFI system for which a user has taken ownership, but which > > has some signed ROMs which are UEFI secure boot verified. Simply to > > get their system to boot the user

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread Vivek Goyal
On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote: > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote: > > On 15.08.2018 22:47, Linus Torvalds wrote: > > > It basically says: we don't allow modules that weren't built with > > > the kernel. Adding a new key later and signing

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread Vivek Goyal
On Wed, Aug 15, 2018 at 09:06:13PM +0200, Yannik Sembritzki wrote: > > > I am wondering why did we have to split this keyring to begin with. > > So there are use cases where we want to trust builtin keys but > > not the ones which came from other places (UEFI secure boot db, or > > user loaded

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread Vivek Goyal
On Wed, Aug 15, 2018 at 01:42:47PM -0400, Vivek Goyal wrote: > On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote: > > Would this be okay? > > [ CC dave young, Baoquan, Justin Forbes] > > Hi Yannik, > > I am reading that bug and wondering that what brok

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-15 Thread Vivek Goyal
On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote: > Would this be okay? [ CC dave young, Baoquan, Justin Forbes] Hi Yannik, I am reading that bug and wondering that what broke it. It used to work, so some change broke it. Justin said that we have been signing fedora kernels

Re: [LKP] [ovl] 24c944dd64: BUG:kernel_reboot-without-warning_in_boot_stage

2018-07-26 Thread Vivek Goyal
On Thu, Jul 26, 2018 at 08:20:56AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: 24c944dd64f807542a2ec72744c81f064d1a60da ("ovl: Modify ovl_lookup() > and friends to lookup metacopy dentry") >

Re: [PATCH 16/28] ovl: Do not expose metacopy only dentry from d_real()

2018-05-30 Thread Vivek Goyal
On Tue, May 29, 2018 at 04:46:00PM +0200, Miklos Szeredi wrote: > From: Vivek Goyal > > Metacopy dentry/inode is internal to overlay and is never exposed outside > of it. Exception is metacopy upper file used for fsync(). Modify d_real() > to look for dentries/inode which have

Re: [PATCH 15/28] ovl: Open file with data except for the case of fsync

2018-05-30 Thread Vivek Goyal
On Wed, May 30, 2018 at 05:12:16PM +0200, Miklos Szeredi wrote: > >> From: Vivek Goyal > >> > >> ovl_open() should open file which contains data and not open metacopy > >> inode. With the introduction of metacopy inodes, with current > >> implem

Re: [PATCH 15/28] ovl: Open file with data except for the case of fsync

2018-05-30 Thread Vivek Goyal
On Tue, May 29, 2018 at 04:45:59PM +0200, Miklos Szeredi wrote: > From: Vivek Goyal > > ovl_open() should open file which contains data and not open metacopy > inode. With the introduction of metacopy inodes, with current > implementaion we will end up opening metacop

Re: [PATCH v2 22/35] vfs: don't open real

2018-05-15 Thread Vivek Goyal
On Mon, May 14, 2018 at 09:58:03AM -0400, Vivek Goyal wrote: [..] > Talked to Dan and he mentioned that he was trying to test entrypoint > failure (and not exec failure) and that's whey he might have allowed exec > to mounter. > > I think that current entrypoint test's expecta

Re: [PATCH v2 22/35] vfs: don't open real

2018-05-14 Thread Vivek Goyal
On Fri, May 11, 2018 at 03:42:48PM -0400, Vivek Goyal wrote: > On Fri, May 11, 2018 at 02:54:30PM -0400, Vivek Goyal wrote: > > On Mon, May 07, 2018 at 10:37:54AM +0200, Miklos Szeredi wrote: > > > Let overlayfs do its thing when opening a file. > > > > >

Re: [PATCH v2 22/35] vfs: don't open real

2018-05-11 Thread Vivek Goyal
On Fri, May 11, 2018 at 02:54:30PM -0400, Vivek Goyal wrote: > On Mon, May 07, 2018 at 10:37:54AM +0200, Miklos Szeredi wrote: > > Let overlayfs do its thing when opening a file. > > > > This enables stacking and fixes the corner case when a file is opened for >

Re: [PATCH v2 22/35] vfs: don't open real

2018-05-11 Thread Vivek Goyal
On Mon, May 07, 2018 at 10:37:54AM +0200, Miklos Szeredi wrote: > Let overlayfs do its thing when opening a file. > > This enables stacking and fixes the corner case when a file is opened for > read, modified through a writable open, and data is read from the read-only > file. After this patch

Re: [PATCH v2 10/35] ovl: deal with overlay files in ovl_d_real()

2018-05-07 Thread Vivek Goyal
On Mon, May 07, 2018 at 10:37:42AM +0200, Miklos Szeredi wrote: > Signed-off-by: Miklos Szeredi > --- > fs/overlayfs/super.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > index e8551c97de51..ad6a5baf226b 100644 >

Re: [RFC PATCH 09/35] ovl: stack file ops

2018-04-26 Thread Vivek Goyal
On Thu, Apr 26, 2018 at 05:01:37PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:56 PM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > >> On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal <vgo...@redha

Re: [RFC PATCH 09/35] ovl: stack file ops

2018-04-26 Thread Vivek Goyal
On Thu, Apr 26, 2018 at 04:43:53PM +0200, Miklos Szeredi wrote: > On Thu, Apr 26, 2018 at 4:13 PM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: > > > > [..] > >> diff --git a/fs/overlayfs/file.c b/fs

Re: [RFC PATCH 09/35] ovl: stack file ops

2018-04-26 Thread Vivek Goyal
On Thu, Apr 12, 2018 at 05:08:00PM +0200, Miklos Szeredi wrote: [..] > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > new file mode 100644 > index ..a0b606885c41 > --- /dev/null > +++ b/fs/overlayfs/file.c > @@ -0,0 +1,76 @@ > +/* > + * Copyright (C) 2017 Red Hat, Inc. > + *

Re: [RFC PATCH 07/35] ovl: copy up file size as well

2018-04-24 Thread Vivek Goyal
On Thu, Apr 12, 2018 at 05:07:58PM +0200, Miklos Szeredi wrote: > Copy i_size of the underlying inode to the overlay inode in ovl_copyattr(). > > This is in preparation for stacking I/O operations on overlay files. > > This patch shouldn't have any observable effect. > > Signed-off-by: Miklos

Re: [RFC PATCH 13/35] ovl: readd fsync

2018-04-23 Thread Vivek Goyal
On Mon, Apr 23, 2018 at 03:39:45PM +0200, Miklos Szeredi wrote: > On Mon, Apr 23, 2018 at 3:36 PM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Apr 12, 2018 at 05:08:04PM +0200, Miklos Szeredi wrote: > >> Implement stacked fsync(). > >> > >> Signed-o

Re: [RFC PATCH 13/35] ovl: readd fsync

2018-04-23 Thread Vivek Goyal
On Thu, Apr 12, 2018 at 05:08:04PM +0200, Miklos Szeredi wrote: > Implement stacked fsync(). > > Signed-off-by: Miklos Szeredi > --- > fs/overlayfs/file.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/fs/overlayfs/file.c

Re: [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper"

2018-04-19 Thread Vivek Goyal
On Wed, Apr 18, 2018 at 03:49:02PM +0200, Miklos Szeredi wrote: > On Wed, Apr 18, 2018 at 3:38 PM, Steven Rostedt wrote: > > On Wed, 18 Apr 2018 13:42:03 +0200 > > Miklos Szeredi wrote: > > > >> On Wed, Apr 18, 2018 at 10:19 AM, Amir Goldstein

Re: [RFC PATCH 24/35] Revert "ovl: fix relatime for directories"

2018-04-13 Thread Vivek Goyal
On Thu, Apr 12, 2018 at 05:08:15PM +0200, Miklos Szeredi wrote: > This reverts commit cd91304e7190b4c4802f8e413ab2214b233e0260. > > Overlayfs no longer relies on the vfs correct atime handling. > > Signed-off-by: Miklos Szeredi > --- > fs/inode.c | 21

Re: [RFC PATCH 04/35] ovl: copy up times

2018-04-13 Thread Vivek Goyal
On Thu, Apr 12, 2018 at 05:07:55PM +0200, Miklos Szeredi wrote: > Copy up mtime and ctime to overlay inode after times in real object are > modified. Be careful not to dirty cachelines when not necessary. > > This is in preparation for moving overlay functionality out of the VFS. > > This patch

Re: linux-next: Signed-off-by missing for commit in the overlayfs tree

2018-04-04 Thread Vivek Goyal
t; > > is missing a Signed-off-by from its author. > > Hi Steven, > > AFAIK for trivial work we are not required to get a signoff from the author. I am fine with putting my Signed-off-by, if it is required. Signed-off-by: Vivek Goyal <vgo...@redhat.com> BTW, I also p

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-18 Thread Vivek Goyal
On Mon, Dec 18, 2017 at 12:39:50PM -0800, Khazhismel Kumykov wrote: > On Mon, Dec 18, 2017 at 10:29 AM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Mon, Dec 18, 2017 at 10:16:02AM -0800, Khazhismel Kumykov wrote: > >> On Mon, Nov 20, 2017 at 8:36 PM, Khazhismel Ku

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-18 Thread Vivek Goyal
On Mon, Dec 18, 2017 at 10:16:02AM -0800, Khazhismel Kumykov wrote: > On Mon, Nov 20, 2017 at 8:36 PM, Khazhismel Kumykov wrote: > > On Fri, Nov 17, 2017 at 11:26 AM, Shaohua Li wrote: > >> On Thu, Nov 16, 2017 at 08:25:58PM -0800, Khazhismel Kumykov wrote: >

Re: [RFC PATCH] blk-throttle: add burst allowance.

2017-12-07 Thread Vivek Goyal
On Thu, Nov 16, 2017 at 08:50:33AM -0800, Shaohua Li wrote: [..] > Can you describe why we need this? It would be great if you can describe the > usage model and an example. Does this work for io.low/io.max or both? Hi Shaohua, Is there any documentation for "io.low" somewhere now. Should we

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

2017-07-20 Thread Vivek Goyal
On Wed, Jun 28, 2017 at 04:01:48PM -0600, Ross Zwisler wrote: > To be able to use the common 4k zero page in DAX we need to have our PTE > fault path look more like our PMD fault path where a PTE entry can be > marked as dirty and writeable as it is first inserted, rather than waiting > for a

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-18 Thread Vivek Goyal
On Tue, Jul 18, 2017 at 09:21:22AM -0400, Stefan Berger wrote: > On 07/18/2017 08:30 AM, Vivek Goyal wrote: > > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote: > > > On 07/18/2017 07:48 AM, Vivek Goyal wrote: > > > > On Mon, Jul 17, 2017 at 04:50:2

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-18 Thread Vivek Goyal
On Tue, Jul 18, 2017 at 08:30:09AM -0400, Vivek Goyal wrote: > On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote: > > On 07/18/2017 07:48 AM, Vivek Goyal wrote: > > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote: > > > > On 07/17/20

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-18 Thread Vivek Goyal
On Tue, Jul 18, 2017 at 08:05:18AM -0400, Stefan Berger wrote: > On 07/18/2017 07:48 AM, Vivek Goyal wrote: > > On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote: > > > On 07/17/2017 02:58 PM, Vivek Goyal wrote: > > > > On Tue, Jul 11, 2017 at 11:05:1

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-18 Thread Vivek Goyal
On Mon, Jul 17, 2017 at 04:50:22PM -0400, Stefan Berger wrote: > On 07/17/2017 02:58 PM, Vivek Goyal wrote: > > On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote: > > > > [..] > > > +/* > > > + * xattr_list_userns_rewrite - Rewrite list of

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-17 Thread Vivek Goyal
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote: [..] > +/* > + * xattr_list_userns_rewrite - Rewrite list of xattr names for user > namespaces > + * or determine needed size for attribute list > + * in case size == 0 > + * >

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

2017-07-12 Thread Vivek Goyal
On Tue, Jul 11, 2017 at 11:05:11AM -0400, Stefan Berger wrote: [..] > @@ -301,14 +721,39 @@ ssize_t > __vfs_getxattr(struct dentry *dentry, struct inode *inode, const char *name, > void *value, size_t size) > { > - const struct xattr_handler *handler; > + const struct

Re: [PATCH 0/3] Enable namespaced file capabilities

2017-06-23 Thread Vivek Goyal
On Fri, Jun 23, 2017 at 03:17:23PM -0500, Serge E. Hallyn wrote: > Quoting Vivek Goyal (vgo...@redhat.com): > > On Thu, Jun 22, 2017 at 02:59:46PM -0400, Stefan Berger wrote: > > > This series of patches primary goal is to enable file capabilities > > > in user n

Re: [PATCH 0/3] Enable namespaced file capabilities

2017-06-23 Thread Vivek Goyal
On Thu, Jun 22, 2017 at 02:59:46PM -0400, Stefan Berger wrote: > This series of patches primary goal is to enable file capabilities > in user namespaces without affecting the file capabilities that are > effective on the host. This is to prevent that any unprivileged user > on the host maps his

Re: [PATCH v4] Introduce v3 namespaced file capabilities

2017-06-20 Thread Vivek Goyal
On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote: > On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman > wrote: > > "Serge E. Hallyn" writes: > > > >> Quoting Stefan Berger (stef...@linux.vnet.ibm.com): > >>> On 06/14/2017 11:05 PM, Serge

Re: kexec, x86/purgatory: Cleanup the unholy mess

2017-03-10 Thread Vivek Goyal
On Fri, Mar 10, 2017 at 03:58:20PM +0100, Thomas Gleixner wrote: > On Fri, 10 Mar 2017, Vivek Goyal wrote: > > I think we probably will have to initialize these global variables in > > purgatory itself and that puts them in .data section and relocation > > works. > &g

Re: kexec, x86/purgatory: Cleanup the unholy mess

2017-03-10 Thread Vivek Goyal
On Fri, Mar 10, 2017 at 02:57:38PM +0100, Thomas Gleixner wrote: > On Fri, 10 Mar 2017, Mike Galbraith wrote: > > On Fri, 2017-03-10 at 13:17 +0100, Thomas Gleixner wrote: > > > The purgatory code defines global variables which are referenced via a > > > symbol lookup in the kexec code (core and

Re: [RFC v2 1/1] shiftfs: uid/gid shifting bind mount

2017-03-02 Thread Vivek Goyal
On Mon, Feb 20, 2017 at 04:47:05PM -0800, James Bottomley wrote: [..] > +static int shiftfs_readlink(struct dentry *dentry, char __user *data, > + int flags) > +{ > + struct dentry *real = dentry->d_fsdata; > + const struct inode_operations *iop =

Re: [RFC v2 1/1] shiftfs: uid/gid shifting bind mount

2017-02-22 Thread Vivek Goyal
On Tue, Feb 21, 2017 at 05:23:26PM -0500, James Bottomley wrote: > On Tue, 2017-02-21 at 11:06 -0500, Vivek Goyal wrote: > > On Mon, Feb 20, 2017 at 04:47:05PM -0800, James Bottomley wrote: > > > > [..] > > > +static struct dentry *shiftfs_lookup(struct inode *di

Re: [RFC v2 1/1] shiftfs: uid/gid shifting bind mount

2017-02-21 Thread Vivek Goyal
On Mon, Feb 20, 2017 at 04:47:05PM -0800, James Bottomley wrote: [..] > +static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry > *dentry, > + unsigned int flags) > +{ > + struct dentry *real = dir->i_private, *new; > + struct inode *reali

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-20 Thread Vivek Goyal
On Sat, Feb 18, 2017 at 07:24:38PM -0800, James Bottomley wrote: [..] > > > Yes, this is a known characteristic of stacked filesystems. Is > > > there some magic I don't know about that would make it easier to > > > reflect hard links as aliases? > > > > I think overlayfs had the same issue

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-17 Thread Vivek Goyal
On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > On Fri, 2017-02-17 at 02:55 +, Al Viro wrote: > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > Hi James, > > > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > >

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-17 Thread Vivek Goyal
On Fri, Feb 17, 2017 at 05:51:18PM +, Al Viro wrote: > On Fri, Feb 17, 2017 at 09:24:40AM -0800, James Bottomley wrote: > > > > What happens when somebody comes along and creates the damn thing on > > > the underlying fs? _Not_ via your code, that is - using the > > > underlying fs mounted

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-16 Thread Vivek Goyal
On Thu, Feb 16, 2017 at 07:51:58AM -0800, James Bottomley wrote: [..] > > Two levels of checks will simplify this a bit. Top level inode will > > belong to the user namespace of caller and checks should pass. And > > mounter's creds will have ownership over the real inode so no > > additional

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-15 Thread Vivek Goyal
On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: [..] > +static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry > *dentry, > + unsigned int flags) > +{ > + struct dentry *real = dir->i_private, *new; > + struct inode *reali

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-15 Thread Vivek Goyal
On Tue, Feb 14, 2017 at 03:45:55PM -0800, James Bottomley wrote: > On Tue, 2017-02-14 at 18:03 -0500, Vivek Goyal wrote: > > On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: > > > > [..] > > > > shiftfs is going to miss out on overlayfs

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

2017-02-14 Thread Vivek Goyal
On Sun, Feb 05, 2017 at 05:18:11PM -0800, James Bottomley wrote: [..] > > shiftfs is going to miss out on overlayfs bug fixes related to user > > credentials differ from mounter credentials, like fd3220d ("ovl: > > update S_ISGID when setting posix ACLs"). I am not sure that this > > specific

Re: [PATCH v2] ovl: drop CAP_SYS_RESOURCE from saved mounter's credentials

2017-01-10 Thread Vivek Goyal
ng file system in > mounter's context") > Cc: Vivek Goyal <vgo...@redhat.com> > Cc: Miklos Szeredi <mszer...@redhat.com> > --- > fs/overlayfs/super.c |9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/fs/overlayfs/supe

Re: [PATCH] ovl: do not ignore disk quota if current task is not privileged

2017-01-10 Thread Vivek Goyal
On Tue, Jan 10, 2017 at 11:06:47AM -0500, Vivek Goyal wrote: > On Tue, Jan 10, 2017 at 02:26:48PM +0300, Konstantin Khlebnikov wrote: > > If overlay was mounted by root then quota set for upper layer does not work > > because overlay now always use mounter's credentials

Re: [PATCH] ovl: do not ignore disk quota if current task is not privileged

2017-01-10 Thread Vivek Goyal
capability CAP_SYS_RESOURCE in root user namespace. > > Signed-off-by: Konstantin Khlebnikov <khlebni...@yandex-team.ru> > Fixes: 1175b6b8d963 ("ovl: do operations on underlying file system in > mounter's context") > Cc: Vivek Goyal <vgo...@redhat.com>

Re: [PATCH] ovl: do not ignore disk quota if current task is not privileged

2017-01-10 Thread Vivek Goyal
ce. This makes sense to me. I too would like quota to take effect for containers on overlay. I will test it. Vivek > > Signed-off-by: Konstantin Khlebnikov <khlebni...@yandex-team.ru> > Fixes: 1175b6b8d963 ("ovl: do operations on underlying file system in > mounter's co

Re: [PATCH RFC V2] purgatory: fix up declarations

2017-01-03 Thread Vivek Goyal
On Fri, Dec 23, 2016 at 12:43:07PM +0100, Nicholas Mc Guire wrote: > Add the missing declarations of basic purgatory functions and variables > used with kexec_purgatory_get_set_symbol() to allow a clean build. > > Fixes: commit 8fc5b4d4121c ("purgatory: core purgatory functionality") >

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

2016-10-21 Thread Vivek Goyal
On Fri, Oct 21, 2016 at 11:53:41AM +0300, Amir Goldstein wrote: > On Thu, Oct 20, 2016 at 11:54 PM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Oct 20, 2016 at 04:46:30PM -0400, Vivek Goyal wrote: > > > > [..] > >> > +static ssize_t ovl_read_i

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

2016-10-21 Thread Vivek Goyal
On Fri, Oct 21, 2016 at 11:12:11AM +0200, Miklos Szeredi wrote: > On Thu, Oct 20, 2016 at 04:54:08PM -0400, Vivek Goyal wrote: > > On Thu, Oct 20, 2016 at 04:46:30PM -0400, Vivek Goyal wrote: > > > > [..] > > > > +static ssize_t ovl_read_iter(st

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

2016-10-20 Thread Vivek Goyal
On Thu, Oct 20, 2016 at 04:46:30PM -0400, Vivek Goyal wrote: [..] > > +static ssize_t ovl_read_iter(struct kiocb *iocb, struct iov_iter *to) > > +{ > > + struct file *file = iocb->ki_filp; > > + bool isupper = OVL_TYPE_UPPER(ovl_path_type(file->f_path.dentry));

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

2016-10-20 Thread Vivek Goyal
On Wed, Oct 12, 2016 at 03:33:26PM +0200, Miklos Szeredi wrote: > This is a proof of concept patch to fix the following. > > /ovl is in overlay mount and /ovl/foo exists on the lower layer only. > > rofd = open("/ovl/foo", O_RDONLY); > rwfd = open("/ovl/foo", O_WRONLY); /* this causes copy up

Re: [PATCH V3 00/11] block-throttle: add .high limit

2016-10-06 Thread Vivek Goyal
On Thu, Oct 06, 2016 at 08:01:42PM +0200, Paolo Valente wrote: > > > Il giorno 06 ott 2016, alle ore 19:49, Vivek Goyal <vgo...@redhat.com> ha > > scritto: > > > > On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote: > > > > [..] &

Re: [PATCH V3 00/11] block-throttle: add .high limit

2016-10-06 Thread Vivek Goyal
On Thu, Oct 06, 2016 at 03:15:50PM +0200, Paolo Valente wrote: [..] > Shaohua, I have just realized that I have unconsciously defended a > wrong argument. Although all the facts that I have reported are > evidently true, I have argued as if the question was: "do we need to > throw away

Re: [PATCH V3 00/11] block-throttle: add .high limit

2016-10-05 Thread Vivek Goyal
On Wed, Oct 05, 2016 at 02:37:00PM +0200, Paolo Valente wrote: [..] > Anyway, to avoid going on with trying speculations and arguments, let > me retry with a practical proposal. BFQ is out there, free. Let's > just test, measure and check whether we have already a solution to > the problems

Re: [PATCH V3 00/11] block-throttle: add .high limit

2016-10-04 Thread Vivek Goyal
On Tue, Oct 04, 2016 at 11:56:16AM -0400, Tejun Heo wrote: > Hello, Vivek. > > On Tue, Oct 04, 2016 at 09:28:05AM -0400, Vivek Goyal wrote: > > On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote: > > > Hi, > > > > > > The background is we don't

Re: [PATCH V3 00/11] block-throttle: add .high limit

2016-10-04 Thread Vivek Goyal
On Mon, Oct 03, 2016 at 02:20:19PM -0700, Shaohua Li wrote: > Hi, > > The background is we don't have an ioscheduler for blk-mq yet, so we can't > prioritize processes/cgroups. So this is an interim solution till we have ioscheduler for blk-mq? > This patch set tries to add basic arbitration >

Re: [PATCH] blk-throttle: fix infinite throttling caused by non-cascading timer wheel

2016-09-27 Thread Vivek Goyal
On Tue, Sep 27, 2016 at 08:57:22AM -0400, Vivek Goyal wrote: > On Mon, Sep 19, 2016 at 03:11:10PM -0600, Jens Axboe wrote: > > On 09/19/2016 03:06 PM, Vivek Goyal wrote: > > > On Tue, Sep 13, 2016 at 09:46:46AM -0400, Vivek Goyal wrote: > > > > > > > &g

Re: [PATCH] blk-throttle: fix infinite throttling caused by non-cascading timer wheel

2016-09-27 Thread Vivek Goyal
On Mon, Sep 19, 2016 at 03:11:10PM -0600, Jens Axboe wrote: > On 09/19/2016 03:06 PM, Vivek Goyal wrote: > > On Tue, Sep 13, 2016 at 09:46:46AM -0400, Vivek Goyal wrote: > > > > > > Hi Hou Tao, > > > > > > [ CC Tejun and Thomas ] > > >

Re: [PATCH] blk-throttle: fix infinite throttling caused by non-cascading timer wheel

2016-09-19 Thread Vivek Goyal
On Tue, Sep 13, 2016 at 09:46:46AM -0400, Vivek Goyal wrote: > > Hi Hou Tao, > > [ CC Tejun and Thomas ] > > Thanks for the patch. I can reproduce it. I am wondering that why are you > doing so many checks. Can't we just check if throttle group is empty or > not. If i

Re: [PATCH] blk-throttle: fix infinite throttling caused by non-cascading timer wheel

2016-09-13 Thread Vivek Goyal
timer function to wait. And when that timer expires, same process will repeat and we will wait again and this can easily be an infinite loop. Solve this issue by starting a new slice only if throttle gropup is empty. If it is not empty, that means there should be an active slice going on. Ideally

[PATCH] lsm,audit,selinux: Introduce a new audit data type LSM_AUDIT_DATA_FILE

2016-09-09 Thread Vivek Goyal
5 scontext=unconfined_u:unconfined_r:test_overlay_client_t:s0:c10,c20 tcontext=unconfined_u:object_r:test_overlay_files_ro_t:s0 tclass=file permissive=0 Notice that now dev information points to "dm-0" device instead of "overlay" device. This makes it clear that check failed on underlying inode and not

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-20 Thread Vivek Goyal
On Wed, Jul 20, 2016 at 09:35:30AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > > IOW, if your kernel forced signature verification, you should not be > > > able to do sig_enforce=0. If you kernel did not have > > >

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-20 Thread Vivek Goyal
On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > > > Command line options are not signed. I thought idea behind secureboot > > was to execute only trusted code and command line options don't enforce > > you to execute unsigned code. > > > >> > >> You can

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-19 Thread Vivek Goyal
On Tue, Jul 19, 2016 at 01:47:28PM +0100, Mark Rutland wrote: > On Tue, Jul 19, 2016 at 08:24:06AM -0400, Vivek Goyal wrote: > > On Tue, Jul 19, 2016 at 11:52:00AM +0100, Mark Rutland wrote: > > > Regardless, this extended syscall changes some underlying assumptions > > >

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-19 Thread Vivek Goyal
On Tue, Jul 19, 2016 at 11:52:00AM +0100, Mark Rutland wrote: > On Tue, Jul 19, 2016 at 08:55:56AM +0800, Dave Young wrote: > > On 07/18/16 at 11:07am, Mark Rutland wrote: > > > On Mon, Jul 18, 2016 at 10:30:24AM +0800, Dave Young wrote: > > > > I do not think it is worth to add another syscall

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-18 Thread Vivek Goyal
On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote: > On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > >

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-18 Thread Vivek Goyal
On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > >  > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: &

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-15 Thread Vivek Goyal
On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote: > On Thursday, July 14, 2016 10:44:14 PM CEST Thiago Jung Bauermann wrote: > > Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann: > > > > > > > Right, but the question remains whether this helps while you allow the > > >

Re: [RFC 3/3] kexec: extend kexec_file_load system call

2016-07-15 Thread Vivek Goyal
On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote: [..] > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd, > +SYSCALL_DEFINE6(kexec_file_load, int, kernel_fd, int, initrd_fd, > unsigned long, cmdline_len, const char __user *, cmdline_ptr, > -

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-15 Thread Vivek Goyal
On Fri, Jul 15, 2016 at 09:49:25AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 03:13:42PM +0200, Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote: > > > The big question is whether this is a realistic case on a secure boot > > > system.

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-13 Thread Vivek Goyal
On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > Indeed - maybe Eric knows better, but I can't see a

Re: [PATCH 1/9] security, overlayfs: provide copy up security hook for unioned files

2016-07-13 Thread Vivek Goyal
creds to create file and then revert back to old creds and release new creds. Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- fs/overlayfs/copy_up.c| 15 +++ include/linux/lsm_hooks.h | 11 +++ include/linux/security.h | 6 ++ security/security.c

Re: [PATCH 1/9] security, overlayfs: provide copy up security hook for unioned files

2016-07-13 Thread Vivek Goyal
On Wed, Jul 13, 2016 at 10:52:34AM -0400, Stephen Smalley wrote: > On 07/13/2016 10:44 AM, Vivek Goyal wrote: > > Provide a security hook to label new file correctly when a file is copied > > up from lower layer to upper layer of a overlay/union mount. > > > > This

[PATCH 4/9] selinux: Implementation for inode_copy_up_xattr() hook

2016-07-13 Thread Vivek Goyal
. Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- security/selinux/hooks.c | 16 1 file changed, 16 insertions(+) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index c82ee54..4fda548 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/h

[PATCH 5/9] selinux: Pass security pointer to determine_inode_label()

2016-07-13 Thread Vivek Goyal
Right now selinux_determine_inode_label() works on security pointer of current task. Soon I need this to work on a security pointer retrieved from a set of creds. So start passing in a pointer and caller can decide where to fetch security pointer from. Signed-off-by: Vivek Goyal <

[PATCH 2/9] selinux: Implementation for inode_copy_up() hook

2016-07-13 Thread Vivek Goyal
the label of lower file and in case of context mount, overlay inode will have the label from context= mount option. Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- security/selinux/hooks.c | 21 + 1 file changed, 21 insertions(+) diff --git a/security/selinux/hooks.c b/se

[RFC PATCH 0/9][V3] Overlayfs SELinux Support

2016-07-13 Thread Vivek Goyal
med into upper/, and it might get label based on work/ dir. So this hooks helps avoiding all these issues. When a new file is created in upper/, it gets its label based on transition rules. For the case of context mount, it gets the label from context= option. Any feedback is welcome. Vi

[PATCH 3/9] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

2016-07-13 Thread Vivek Goyal
module does not handle/manage the xattr, or a -errno upon an error. Signed-off-by: David Howells <dhowe...@redhat.com> Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- fs/overlayfs/copy_up.c| 7 +++ include/linux/lsm_hooks.h | 10 ++ include/linux/secu

[PATCH 8/9] overlayfs: Dilute permission checks on lower only if not special file

2016-07-13 Thread Vivek Goyal
-by: Dan Walsh <dwa...@redhat.com> Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- fs/overlayfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c index 66f42f5..6d9d86e 100644 --- a/fs/overlayfs/inode.c +++ b/fs/overl

[PATCH 1/9] security, overlayfs: provide copy up security hook for unioned files

2016-07-13 Thread Vivek Goyal
to old creds and release new creds. Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- fs/overlayfs/copy_up.c| 18 ++ include/linux/lsm_hooks.h | 11 +++ include/linux/security.h | 6 ++ security/security.c | 8 4 files changed, 43 inse

[PATCH 6/9] security, overlayfs: Provide hook to correctly label newly created files

2016-07-13 Thread Vivek Goyal
of creds appropriately. Caller makes use of these new creds for file creation. Signed-off-by: Vivek Goyal <vgo...@redhat.com> --- fs/overlayfs/dir.c| 10 ++ include/linux/lsm_hooks.h | 15 +++ include/linux/security.h | 12 security/security.c

  1   2   3   4   5   6   7   8   9   10   >