hello, I want to consult you on what is the original intention of designing subtree_check and whether it is to solve the 'I want to export a subtree of a filesystem' problem. As far as I know, when opening subtree_check, the folder's file handle does not contain the inode information of its parent directory and 'while (tdentry != exp->ex_path.dentry && !IS_ROOT(tdentry))' in nfsd_acceptable can work well to Intercept handles beyond the export point. This seems to delete code as follows in nfsfh.c could solve the 'I want to export a subtree of a filesystem' problem and ensure safety: if (exp->ex_flags & NFSEXP_NOSUBTREECHECK) return 1; Or replace by follow: if (exp->ex_path.dentry == exp->vfs_mount->mnt_root) return 1; When I was reading the nfsd code, I was confused about whether the designer used the file system as a security boundary or an export point.Since exporting a complete file system is the safest, why not directly prohibit unsafe practices, but add code like subtree_check to try to verify the file handle. I may not understand your design ideas. Yours sincerely, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> 于2021年1月13日周三 上午12:53写道： > > On Tue, 2021-01-12 at 10:32 -0500, J. Bruce Fields wrote: > > On Tue, Jan 12, 2021 at 10:48:00PM +0800, 吴异 wrote: > > > Telling users how to configure the exported file system in the most > > > secure > > > way does > > > mitigate the problem to some extent, but this does not seem to > > > address the > > > security risks posed by no_ subtree_ check in the code. In my > > > opinion,when > > > the generated filehandle does not contain the inode information of > > > the > > > parent directory,the nfsd_acceptable function can also recursively > > > determine whether the request file exceeds the export path > > > dentry.Enabling > > > subtree_check to add parent directory information only brings some > > > troubles. > > > > Filesystems don't necessarily provide us with an efficient way to > > find > > parent directories from any given file. (And note a single file may > > have multiple parent directories.) > > > > (I do wonder if we could do better in the directory case, though. We > > already reconnect directories all the way back up to the root.) > > > > > I have a bold idea, why not directly remove the file handle > > > modification in > > > subtree_check, and then normalize the judgment of whether dentry > > > exceeds > > > the export point directory in nfsd_acceptable (line 38 to 54 in > > > /fs/nfsd/nfsfh.c) . > > > > > > As far as I understand it, the reason why subtree_check is not > > > turned on by > > > default is that it will cause problems when reading and writing > > > files, > > > rather than it wastes more time when nfsd_acceptable. > > > > > > In short,I think it's open to question whether the security of the > > > system > > > depends on the user's complete correct configuration(the system > > > does not > > > prohibit the export of a subdirectory). > > > > > Enabling subtree_check to add parent directoryinformation only > > > brings > > > some troubles. > > > > > > In short,I think it's open to question whether the security of the > > > system depends on the user's complete correct configuration(the > > > system > > > does not prohibit the export of a subdirectory). > > > > I'd love to replace the export interface by one that prohibited > > subdirectory exports (or at least made it more obvious where they're > > being used.) > > > > But given the interface we already have, that would be a disruptive > > and > > time-consuming change. > > > > Another approach is to add more entropy to filehandles so they're > > harder > > to guess; see e.g.: > > > > https://www.fsl.cs.stonybrook.edu/docs/nfscrack-tr/index.html > > > > In the end none of these change the fact that a filehandle has an > > infinite lifetime, so once it's leaked, there's nothing you can do. > > The > > authors suggest NFSv4 volatile filehandles as a solution to that > > problem, but I don't think they've thought through the obstacles to > > making volatile filehandles work. > > > > --b. > > The point is that there is no good solution to the 'I want to export a > subtree of a filesystem' problem, and so it is plainly wrong to try to > make a default of those solutions, which break the one sane case of > exporting the whole filesystem. > > Just a reminder that we kicked out subtree_check not only because a > trivial rename of a file breaks the client's ability to perform I/O by > invalidating the filehandle. In addition, that option causes filehandle > aliasing (i.e. multiple filehandles pointing to the same file) which is > a major PITA for clients to try to manage for more or less the same > reason that it is a major PITA to try to manage these files using > paths. > > The discussion on volatile filehandles in RFC5661 does try to address > some of the above issues, but ends up concluding that you need to > introduce POSIX-incompatible restrictions, such as trying to ban > renames and deletions of open files in order to make it work. > > None of these compromises are necessary if you export a whole > filesystem (or a hierarchy of whole filesystems). That's the sane case. > That's the one that people should default to using. > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
