On Wed, Jan 14, 2026 at 2:41 PM Jeff Layton <[email protected]> wrote: > > On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote: > > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <[email protected]> > > > wrote: > > > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > > Fair point, but it's not that hard to conceive of a situation where > > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > > > Sure. But how is this worse than accidentally exporting private data > > > > or any other misconfiguration? > > > > > > > > > > My POV is that it is less about security (as your question implies), and > > > more about correctness. > > > > I was just replying to Jeff. > > > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > > open by file handle, IOW, the export_operations. > > > > > > I perceive this as a very strange and undesired situation when NFS > > > file handles do not behave as persistent file handles. > > > > That is not just very strange, but actually broken (discounting the > > obscure volatile file handles features not implemented in Linux NFS > > and NFSD). And the export ops always worked under the assumption > > that these file handles are indeed persistent. If they're not we > > do have a problem. > > > > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > > a known reason, which was NOT NFS export. > > > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > > wish to imply that those fs should be exported to NFS, why object? > > > > Because "want to export" is a stupid category. > > > > OTOH "NFS exporting doesn't actually properly work because someone > > overloaded export_ops with different semantics" is a valid category. > > > > cgroupfs definitely doesn't behave as expected when exported via NFS. > The files aren't readable, at least. I'd also be surprised if the > filehandles were stable across a reboot, which is sort of necessary for > proper operation. I didn't test writing, but who knows whether that > might also just not work, crash the box, or do something else entirely. > > I imagine this is the case for all sorts of filesystems like /proc, > /sys, etc. Those aren't exportable today (to my knowledge), but we're > growing export_operations across a wide range of fs's these days. > > I'd prefer that we require someone to take the deliberate step to say > "yes, allow nfsd to access this type of filesystem". > > > > We could have the opt-in/out of NFS export fixes per EXPORT_OP_ > > > flags and we could even think of allowing admin to make this decision > > > per vfsmount (e.g. for cgroupfs). > > > > > > In any case, I fail to see how objecting to the possibility of NFS export > > > opt-out serves anyone. > > > > You're still think of it the wrong way. If we do have file systems > > that break the original exportfs semantics we need to fix that, and > > something like a "stable handles" flag will work well for that. But > > a totally arbitrary "is exportable" flag is total nonsense. >
Very well then. How about EXPORT_OP_PERSISTENT_HANDLES? This terminology is from the NFS protocol spec and it is also used to describe the same trait in SMB protocol. > The problem there is that we very much do want to keep tmpfs > exportable, but it doesn't have stable handles (per-se). Thinking out loud - It would be misguided to declare tmpfs as EXPORT_OP_PERSISTENT_HANDLES and regressing exports of tmpfs will surely not go unnoticed. How about adding an exportfs option "persistent_handles", use it as default IFF neither options fsid=, uuid= are used, so that at least when exporting tmpfs, exportfs -v will show "no_persistent_handles" explicitly? Thanks, Amir.
