On Fri, Dec 6, 2024 at 5:03 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> On Thu, Dec 05, 2024 at 12:57:28PM +0100, Amir Goldstein wrote:
> > On Thu, Dec 5, 2024 at 1:38 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > >
> > > On Sun, Dec 01, 2024 at 02:12:24PM +0100, Christian Brauner wrote:
> > > > Hey,
> > > >
> > > > Some filesystems like kernfs and pidfs support file handles as a
> > > > convenience to enable the use of name_to_handle_at(2) and
> > > > open_by_handle_at(2) but don't want to and cannot be reliably exported.
> > > > Add a flag that allows them to mark their export operations accordingly
> > > > and make NFS check for its presence.
> > > >
> > > > @Amir, I'll reorder the patches such that this series comes prior to the
> > > > pidfs file handle series. Doing it that way will mean that there's never
> > > > a state where pidfs supports file handles while also being exportable.
> > > > It's probably not a big deal but it's definitely cleaner. It also means
> > > > the last patch in this series to mark pidfs as non-exportable can be
> > > > dropped. Instead pidfs export operations will be marked as
> > > > non-exportable in the patch that they are added in.
> > >
> > > Can you please invert the polarity? Marking something as not supporting
> > > is always awkward. Clearly marking it as supporting something (and
> > > writing down in detail what is required for that) is much better, even
> > > it might cause a little more churn initially.
> > >
> >
> > Churn would be a bit annoying, but I guess it makes sense.
> > I agree with Christian that it should be done as cleanup to allow for
> > easier backport.
> >
> > Please suggest a name for this opt-in flag.
> > EXPORT_OP_NFS_EXPORT???
>
> That's probably too specific to NFS--
>
> AFAICT the goal here is to prevent exporting {pid,kern}fs file handles
> to other nodes, correct? Because we don't want to allow a process on
> another computer to mess around with processes on the local computer?
>
> How about:
>
> /* file handles can be used by a process on another node */
> #define EXPORT_OP_ALLOW_REMOTE_NODES (...)
This has a sound of security which is incorrect IMO.
The fact that we block nfsd export of cgroups does not prevent
any type of userland file server from exporting cgroup file handles.
I hate to be a pain, but IMO, the claim that inverted polarity is clearer
is not a consensus and there are plenty of counter examples.
I do not object to inverting the polarity if a flag name is found
that explains the property well, but IMO, this is not it.
Maybe opt-out of nfsd export is a little less safer than opt-in, but
1. opt-out is and will remain the rare exception for export_operations
2. at least the flag name EXPORT_OP_LOCAL_FILE_HANDLE
is pretty clear IMO
Plus, as I wrote in another email, the fact that pidfs is SB_NOUSER,
so userspace is not allowed to mount it into the namespace and
userland file servers cannot export the filesystem itself.
That property itself (SB_NOUSER), is therefore a good enough indication
to deny nfsd export of this fs.
So really the immediate need for an explicit flag is only to stop exporting
kernfs/cgroupfs and I don't see this need spreading much further
(perhaps to nsfs) and therefore, the value of inverting to opt-in is
questionable IMO.
Thanks,
Amir.
