On Sat, Jan 04, 2020 at 12:14:26PM -0800, James Bottomley wrote: > fsconfig is a very powerful configuration mechanism except that it > only works for filesystems with superblocks. This patch series > generalises the useful concept of a multiple step configurational > mechanism carried by a file descriptor. The object of this patch > series is to get bind mounts to be configurable in the same way that > superblock based ones are, but it should have utility beyond the > filesytem realm. Patch 4 also reimplements fsconfig in terms of > configfd, but that's not a strictly necessary patch, it is merely a > useful demonstration that configfd is a superset of the properties of > fsconfig. Thanks for the patch. I'm glad fsconfig() is picked back up; either by you or by David. We will need this for sure. But the configfd approach does not strike me as a great idea. Anonymous inode fds provide an abstraction mechanism for kernel objects which we built around fds such as timerfd, pidfd, mountfd and so on. When you stat an anonfd you get ANON_INODE_FS_MAGIC and you get the actual type by looking at fdinfo, or - more common - by parsing out /proc/<pid>/fd/<nr> and discovering "[fscontext]". So it's already a pretty massive abstraction layer we have. But configfd would be yet another fd abstraction based on anonfds. The idea has been that a new fd type based on anonfds comes with an api specific to that type of fd. That seems way nicer from an api design perspective than implementing new apis as part of yet another generic configfd layer. Another problem is that these syscalls here would be massive multiplexing syscalls. If they are ever going to be used outside of filesystem use-cases (which is doubtful) they will quickly rival prctl(), seccomp(), and ptrace(). That's not a great thing. Especially, since we recently (a few months ago with Linus chiming in too) had long discussions with the conclusion that multiplexing syscalls are discouraged, from a security and api design perspective. Especially when they are not tied to a specific API (e.g. seccomp() and bpf() are at least tied to a specific API). libcs such as glibc and musl had reservations in that regard as well. This would also spread the mount api across even more fd types than it already does now which is cumbersome for userspace. A generic API like that also makes it hard to do interception in userspace which is important for brokers such as e.g. used in Firefox or what we do in various container use-cases. So I have strong reservations about configfd and would strongly favor the revival of the original fsconfig() patchset. Christian
