From: Patrick Goetz <pgoetz@math.utexas.edu>
To: "bfields@fieldses.org" <bfields@fieldses.org>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
"wangzhibei1999@gmail.com" <wangzhibei1999@gmail.com>,
"security@kernel.org" <security@kernel.org>,
"w@1wt.eu" <w@1wt.eu>, "greg@kroah.com" <greg@kroah.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Subject: Re: nfsd vurlerability submit
Date: Thu, 21 Jan 2021 17:19:32 -0600 [thread overview]
Message-ID: <a6429a2c-ce90-caec-0704-6626cd564300@math.utexas.edu> (raw)
In-Reply-To: <20210121220402.GF20964@fieldses.org>
On 1/21/21 4:04 PM, bfields@fieldses.org wrote:
> On Thu, Jan 21, 2021 at 02:01:13PM -0600, Patrick Goetz wrote:
>> I didn't respond to this message immediately, but it's been
>> bothering me ever since. When I do a bind mount like this in
>> /etc/fstab:
>>
>> /data2/xray /srv/nfs/xray none defaults,bind 0
>>
>> it's my understanding that the kernel keeps track of the resulting
>> /srv/nfs/xray filesystem in it's vfs somehow. Even when directly on
>> the server I can't "break out" of /srv/nfs/xray to get to the other
>> directories in /data. Then how on earth would an NFS client do
>> this?
>
> As I said, NFS allows you to look up objects by filehandle (so,
> basically by inode number), not just by path
Except surely this doesn't buy you much if you don't have root access to
the system? Is this all only an issue when the filesystems are exported
with no_root_squash?
I feel like I must be missing something, but it seems to me that if I'm
not root, I'm not going to be able to access inodes I don't have
permissions to access even when directly connected to the exporting server.
>
> Also, note, mounting something over a directory doesn't hide what's
> under the mountpoint. And it's unwise to depend on directory
> permissions alone to hide contents of anything underneath that
> directory.
Well, I only ever bind mount over empty directories; but again, "doesn't
hide what's under the mount point" from whom? I'm sure root can get to
this somehow, but can someone with ordinary user access? even if the
user doesn't have permissions to access the stuff that's been mounted over?
>
>> I thought the whole point of doing a bind mount like this is to
>> solve the problem of exporting leaves of a directory hierarchy. In
>> particular,
>>
>> "So in your example, if /data2/xray is on the same filesystem as
>> /data2, then the server will happily allow operations on
>> filehandles anywhere in /data2."
>>
>> Yes, sure; but I'm not exporting /data2/xray; I'm exporting
>> /srv/nfs/xray, a bind mount to the preceding. Am I missing
>> something, or is NFS too insecure to use in any context requiring
>> differentiated security settings on different folders in the same
>> directory structure?
>
> Definitely do *not* depend on NFS to enforce different export options on
> different subdirectories of the same filesystem.
>
>> It's not practical to making everything you export its own partition;
>> although I suppose one could do this with ZFS datasets.
>
> I'd be happy to hear about any use cases where that's not practical.
>
Sure. The xray example is taken from one of my research groups which
collects thousands of very large electron microscopy images, along with
some xray data. I will certainly design this differently in the next
iteration (most likely using ZFS), but our current server has a 519T
attached storage device which presents itself as a single device:
/dev/sdg. Different groups need access to different classes of data,
which I export separately and with are presented on the workstations as
/xray, /EM, etc..
Yes, I could partition the storage device, but then I run into the usual
issues where one partition runs out of space while others are barely
utilized. This is one good reason to switch to ZFS datasets. The other
is that -- with 450T+ of ever changing data, currently rsync backups are
almost impossible. I'm hoping zfs send/receive is going to save me here.
> As Christophe pointed out, xfs/ext4 project ids are another option.
>
> --b.
>
I must have missed this one, but it just leaves me more confused.
Project ID's are filesystem metadata, yet this affords better boundary
enforcement than a bind mount? Also, the only use case for Project ID's
I was able to find are project quotas, so am not even sure how this
would be implemented, and used by NFS.
next prev parent reply other threads:[~2021-01-21 23:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHxDmpTKJfnhGY9CVupyVYhNCTDVKBB6KRwh-E6u_XEPJq4WJQ@mail.gmail.com>
[not found] ` <20210105165633.GC14893@fieldses.org>
[not found] ` <X/hEB8awvGyMKi6x@kroah.com>
[not found] ` <20210108152017.GA4183@fieldses.org>
[not found] ` <CAHxDmpSp1LHzKD5uqbfi+jcnb+nFaAZbc5++E0oOvLsYvyYDpw@mail.gmail.com>
[not found] ` <20210108164433.GB8699@fieldses.org>
[not found] ` <CAHxDmpSjwrcr_fqLJa5=Zo=xmbt2Eo9dcy6TQuoU8+F3yVVNhw@mail.gmail.com>
[not found] ` <20210110201740.GA8789@fieldses.org>
[not found] ` <20210110202815.GB8789@fieldses.org>
[not found] ` <CAHxDmpR8S7NR8OU2nWJmWBdFU9a7wDuDnxviQ2E9RDOeW9fExg@mail.gmail.com>
2021-01-11 19:25 ` nfsd vurlerability submit J. Bruce Fields
2021-01-11 21:01 ` [PATCH] nfsd4: readdirplus shouldn't return parent of export J. Bruce Fields
2021-01-12 13:31 ` Chuck Lever
2021-01-12 13:50 ` Bruce Fields
[not found] ` <20210108152607.GA950@1wt.eu>
[not found] ` <20210108153237.GB4183@fieldses.org>
[not found] ` <20210108154230.GB950@1wt.eu>
[not found] ` <20210111193655.GC2600@fieldses.org>
[not found] ` <CAHxDmpR1zG25ADfK2jat4VKGbAOCg6YM_0WA+a_jQE82hbnMjA@mail.gmail.com>
[not found] ` <CAHxDmpRfmVukMR_yF4coioiuzrsp72zBraHWZ8gaMydUuLwKFg@mail.gmail.com>
2021-01-12 15:32 ` nfsd vurlerability submit J. Bruce Fields
2021-01-12 16:53 ` Trond Myklebust
2021-01-12 17:20 ` Patrick Goetz
2021-01-12 18:03 ` bfields
2021-01-13 8:12 ` Christoph Hellwig
2021-01-13 14:34 ` Trond Myklebust
2021-01-13 14:40 ` hch
2021-01-13 15:16 ` Trond Myklebust
2021-01-13 15:30 ` hch
2021-01-13 15:45 ` Frank Filz
2021-01-21 20:01 ` Patrick Goetz
2021-01-21 22:04 ` bfields
2021-01-21 23:19 ` Patrick Goetz [this message]
2021-01-22 1:30 ` bfields
2021-01-22 13:20 ` Patrick Goetz
2021-01-22 14:48 ` Tom Talpey
[not found] ` <CAHxDmpTEBJ1jd_fr3GJ4k7KgzaBpe1LwKgyZn0AJ0D1ESK12fQ@mail.gmail.com>
2021-01-12 17:47 ` Trond Myklebust
[not found] ` <CAHxDmpTyrG74hOkzmDK834t+JiQduWHVWxCf_7nrDVa++EK2mA@mail.gmail.com>
2021-01-13 14:25 ` Trond Myklebust
2021-01-14 18:07 ` bfields
2021-01-14 18:29 ` Linus Torvalds
2021-01-14 18:35 ` Chuck Lever
2021-01-14 18:37 ` Linus Torvalds
2021-01-18 16:29 ` 吴异
2021-01-18 22:55 ` bfields
2021-01-19 2:48 ` 吴异
2021-01-19 3:46 ` bfields
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=a6429a2c-ce90-caec-0704-6626cd564300@math.utexas.edu \
--to=pgoetz@math.utexas.edu \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=greg@kroah.com \
--cc=linux-nfs@vger.kernel.org \
--cc=security@kernel.org \
--cc=trondmy@hammerspace.com \
--cc=w@1wt.eu \
--cc=wangzhibei1999@gmail.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 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.