chucklever
commented
7 months ago [J. Bruce Fields 2022-01-23 17:27:40 UTC] Implementation notes:
When looking up a filehandle, we should add a check that the project ID of the looked-up inode agrees with the project ID of the export root. STALE is probably the right error to return if they don't. I'm not sure exactly where that check should go. The project ID is currently only in filesystem-specific fields (like ext4_inode_info->i_projid). Looks like some modification of the nfsd/filesystem interface will be needed.
I'm not sure if it's safe to turn on that behavior by default.
We could turn it on only in the case the export root is not the filesystem root, and then the only case where it would be a problem would the case where somebody is both exporting a subdirectory, and is already using project IDs for something else and does not want it limiting exports. Perhaps that's rare enough to be OK.
If that's not OK, we could define a new export flag to control the behavior.
We should check with filesystem developers to see what they think.
This was bugzilla.linux-nfs.org 378
[J. Bruce Fields 2022-01-23 17:06:41 UTC] XFS and ext4 support a "project ID" which tags each inode with a 32-bit value that can be inherited by files and subdirectories. We should allow exporting only those objects on a filesystem that have a given project ID.
This allows you to export a subtree of a filesystem without risking that an attacker could escape the subtree by filehandle-guessing attacks (since the server can get the project ID directly from the inode), and without the drawbacks of nosubtreecheck (since there's no need to encode the parent in filehandles).
The most recent discussion I can find is https://lore.kernel.org/linux-nfs/20210113153013.GA1527598@infradead.org/#t.
Looks like there's also a little documentation in ioctl_xfs_fsgetxattr(2) and xfs_quota(8).
This should be useful and not too difficult to implement.