Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]

On Tue, Mar 03, 2020 at 12:33:48PM +0100, Miklos Szeredi wrote:

On Tue, Mar 3, 2020 at 11:25 AM Christian Brauner
[off-list ref] wrote:

quoted

On Tue, Mar 03, 2020 at 11:13:50AM +0100, Miklos Szeredi wrote:

quoted

On Tue, Mar 3, 2020 at 11:00 AM Christian Brauner
[off-list ref] wrote:

quoted

quoted

quoted

More magic links to beam you around sounds like a bad idea. We had a
bunch of CVEs around them in containers and they were one of the major
reasons behind us pushing for openat2(). That's why it has a
RESOLVE_NO_MAGICLINKS flag.

No, that link wouldn't beam you around at all, it would end up in an
internally mounted instance of a mountfs, a safe place where no

Even if it is a magic link to a safe place it's a magic link. They
aren't a great solution to this problem. fsinfo() is cleaner and
simpler as it creates a context for a supervised mount which gives the a
managing application fine-grained control and makes it easily
extendable.

Yeah, it's a nice and clean interface in the ioctl(2) sense. Sure,
fsinfo() is way better than ioctl(), but it at the core it's still the
same syscall multiplexer, do everything hack.

In contrast to a generic ioctl() it's a domain-specific separate
syscall. You can't suddenly set kvm options through fsinfo() I would
hope. I find it at least debatable that a new filesystem is preferable.
And - feel free to simply dismiss the concerns I expressed - so far
there has not been a lot of excitement about this idea.

quoted

Also, we're apparently at the point where it seems were suggesting
another (pseudo)filesystem to get information about filesystems.

Implementation detail.  Why would you care?

I wouldn't call this an implementation detail. That's quite a big
design choice; it's a separate fileystem. In addition, implementation
details need to be maintained.

Christian