From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Mark Salyzyn <salyzyn@android.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
kernel-team@android.com, Jonathan Corbet <corbet@lwn.net>,
Vivek Goyal <vgoyal@redhat.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Randy Dunlap <rdunlap@infradead.org>,
Stephen Smalley <sds@tycho.nsa.gov>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-doc@vger.kernel.org,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH v14 2/5] overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh
Date: Sun, 27 Oct 2019 09:24:52 +0200 [thread overview]
Message-ID: <CAOQ4uxh_K=p7z+qbkjSf_+hhVsw9xBuNc61dYnpkHFVUfxJaCw@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegsCzwXF5fD1oA+XMrPQ7u8URsXRGOOHkB=ON7fLnd_gFQ@mail.gmail.com>
+ ebiederm and nfsd folks
On Wed, Oct 23, 2019 at 11:08 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>
>
> On Tue, Oct 22, 2019 at 10:46 PM Mark Salyzyn <salyzyn@android.com> wrote:
> >
> > Assumption never checked, should fail if the mounter creds are not
> > sufficient.
>
> A bit more explanation would be nice. Like a pointer to the explanation given in the open_by_handle_at(2) code where this check was presumably taken from.
>
Well, it's not that simple (TM).
If you are considering unprivileged overlay mounts, then this should be
ns_capable() check, even though open_by_handle_at(2) does not
currently allow userspace nfsd to decode file handles.
Unlike open_by_handle_at(2), overlayfs (currently) never exposes file
data via decoded origin fh. AFAIK, it only exposes the origin st_ino
st_dev and some nlink related accounting.
I have been trying to understand from code if nfsd exports are allowed
from non privileged containers and couldn't figure it out (?).
If non privileged container is allowed to export nosubtreecheck export
then non privileged container root can already decode file handles...
Thanks,
Amir.
next parent reply other threads:[~2019-10-27 7:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191022204453.97058-1-salyzyn@android.com>
[not found] ` <20191022204453.97058-3-salyzyn@android.com>
[not found] ` <CAJfpegsCzwXF5fD1oA+XMrPQ7u8URsXRGOOHkB=ON7fLnd_gFQ@mail.gmail.com>
2019-10-27 7:24 ` Amir Goldstein [this message]
2019-10-28 16:27 ` [PATCH v14 2/5] overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh J. Bruce Fields
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='CAOQ4uxh_K=p7z+qbkjSf_+hhVsw9xBuNc61dYnpkHFVUfxJaCw@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=bfields@fieldses.org \
--cc=corbet@lwn.net \
--cc=ebiederm@xmission.com \
--cc=jlayton@kernel.org \
--cc=kernel-team@android.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=rdunlap@infradead.org \
--cc=salyzyn@android.com \
--cc=sds@tycho.nsa.gov \
--cc=vgoyal@redhat.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).