On 1/21/21 4:04 PM, bfields@xxxxxxxxxxxx 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.
