From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
"rgoldwyn@suse.de" <rgoldwyn@suse.de>,
"agruenba@redhat.com" <agruenba@redhat.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: nfs4_acl restricts copy_up in overlayfs
Date: Fri, 1 Jun 2018 13:43:36 -0400 [thread overview]
Message-ID: <20180601174336.GF10666@fieldses.org> (raw)
In-Reply-To: <CAJfpeguFobmD5EdvYU7eFaaShMYxt9j72k=GKGHyh3-D-uCB-Q@mail.gmail.com>
On Fri, Jun 01, 2018 at 07:02:20PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 1, 2018 at 6:08 PM, bfields@fieldses.org
> <bfields@fieldses.org> wrote:
> > On Fri, Jun 01, 2018 at 04:43:51PM +0200, Miklos Szeredi wrote:
> >> Look at ovl_permission(), I think it pretty clearly describes this model.
> >
> > Thanks! Uh, so generic_permission is the thing that just does the usual
> > mode/acl checks on the in-core inode, and inode_permission is the one
> > that also calls into the filesystem?
>
> Right.
>
> > But I'm still a little confused--if I'm reading right, "realinode" is
> > the lower inode before copyup, and the upper inode after, so can't
> > inode_permission(realinode, mask) return different results before and
> > after copyup?
>
> Theoretically, yes. Not in any sane setup, though.
If root squashing is enabled and you mount as root, then it will change.
That's not an unlikely case, it's pretty much the default.
--b.
>
> The inode_permission() checks on realinode are for making sure the
> mounter cannot gain undue privileges (will be especially important
> with userns mounts).
next prev parent reply other threads:[~2018-06-01 17:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 20:32 nfs4_acl restricts copy_up in overlayfs Goldwyn Rodrigues
2018-05-29 21:37 ` Trond Myklebust
2018-05-30 1:08 ` Goldwyn Rodrigues
2018-05-30 3:01 ` Trond Myklebust
2018-05-30 10:33 ` Goldwyn Rodrigues
2018-05-31 0:45 ` J. Bruce Fields
2018-05-31 10:00 ` Miklos Szeredi
2018-05-31 12:47 ` Trond Myklebust
2018-05-31 12:55 ` Miklos Szeredi
2018-05-31 13:10 ` Trond Myklebust
2018-05-31 13:30 ` Miklos Szeredi
2018-05-31 14:06 ` bfields
2018-05-31 14:26 ` Miklos Szeredi
2018-05-31 17:52 ` Trond Myklebust
2018-05-31 21:56 ` Goldwyn Rodrigues
2018-05-31 21:53 ` Goldwyn Rodrigues
2018-06-01 0:49 ` Trond Myklebust
2018-06-01 11:40 ` Goldwyn Rodrigues
2018-06-01 13:16 ` Trond Myklebust
2018-06-01 13:32 ` Miklos Szeredi
2018-06-01 13:50 ` bfields
2018-06-01 14:00 ` Miklos Szeredi
2018-06-01 14:26 ` bfields
2018-06-01 14:43 ` Miklos Szeredi
2018-06-01 16:08 ` bfields
2018-06-01 17:02 ` Miklos Szeredi
2018-06-01 17:43 ` bfields [this message]
2018-06-01 19:14 ` Miklos Szeredi
2018-06-02 0:50 ` bfields
2018-06-07 11:50 ` Miklos Szeredi
2018-05-31 18:57 ` J. R. Okajima
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=20180601174336.GF10666@fieldses.org \
--to=bfields@fieldses.org \
--cc=agruenba@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rgoldwyn@suse.de \
--cc=trondmy@hammerspace.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).