All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>, linux-unionfs@vger.kernel.org
Subject: Re: [PATCH] overlayfs: Do not lose security.capability xattr over metadata file copy-up
Date: Wed, 30 Jan 2019 10:43:12 -0500	[thread overview]
Message-ID: <20190130154312.GA2757@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhAsVgkxND=Bj-jrZf307_+e=E6Zg+a1kOiFaGh1YBuEQ@mail.gmail.com>

On Wed, Jan 30, 2019 at 09:42:19AM +0200, Amir Goldstein wrote:
> On Tue, Jan 29, 2019, 10:50 PM Vivek Goyal <vgoyal@redhat.com wrote:
> 
> > If a file has been copied up metadata only, and later data is copied up,
> > upper loses any security.capability xattr it has (underlying filesystem
> > clears it as upon file write).
> >
> 
> 
> Write also clears suid mode bits
> Should we restore these as well? Or do we already and I missed it?

[ Adding linux-unionfs ]

suid mode bit is only cleared if caller does not have CAP_FSETID.

should_remove_suid() {
        if (unlikely(kill && !capable(CAP_FSETID) && S_ISREG(mode)))
                return kill;
}

We do copy up in the context of mounter which is root, often with
CAP_FSETID.

So while this is not a widespread problem yet, it is a potential issue.
We can fix it if somebody runs into it.

> 
> 
> > From a user's point of view, this is just a file copy-up and that should
> > not result in losing security.capability xattr. Hence, before data copy
> > up, save security.capability xattr (if any) and restore it on upper after
> > data copy up is complete.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> >  fs/overlayfs/copy_up.c   |   24 +++++++++++++++++++++++-
> >  fs/overlayfs/overlayfs.h |    1 +
> >  fs/overlayfs/util.c      |   44
> > ++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 68 insertions(+), 1 deletion(-)
> >
> > Index: rhvgoyal-linux/fs/overlayfs/util.c
> > ===================================================================
> > --- rhvgoyal-linux.orig/fs/overlayfs/util.c     2019-01-28
> > 14:42:10.499670636 -0500
> > +++ rhvgoyal-linux/fs/overlayfs/util.c  2019-01-29 14:45:49.747395201 -0500
> > @@ -912,3 +912,47 @@ invalid:
> >         res = -EINVAL;
> >         goto err_free;
> >  }
> > +
> > +size_t ovl_getxattr(struct dentry *dentry, char *name, void **value,
> > +                               size_t *size)
> > +{
> >
> 
> 
> Please add padding arg and use this helper from ovl_get_redirect_xattr.

Ok, will do.

Vivek

      parent reply	other threads:[~2019-01-30 15:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29 20:50 [PATCH] overlayfs: Do not lose security.capability xattr over metadata file copy-up Vivek Goyal
     [not found] ` <CAOQ4uxhAsVgkxND=Bj-jrZf307_+e=E6Zg+a1kOiFaGh1YBuEQ@mail.gmail.com>
2019-01-30 15:43   ` Vivek Goyal [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190130154312.GA2757@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.