LWN：configfd() and shifting bind mounts

最新推荐文章于 2024-07-09 13:38:12 发布

LinuxNews搬运工

最新推荐文章于 2024-07-09 13:38:12 发布

阅读量133

点赞数

原文链接：https://lwn.net/Articles/809125/

版权

关注了就能看到更多这么棒的文章哦～

configfd() and shifting bind mounts

By Jonathan Corbet
January 10, 2020

原文来自：https://lwn.net/Articles/809125/

5.2 kernel中新增了一个新API来进行文件系统mount和remount。2018年的LWN文章中有介绍过这个API的早期版本，后来人们就一直在逐个文件系统来增加对此API的支持。James Bottomley在重新设计shitfs filesystem的时候仔细看了看这个API，发现它并不完整。后面就进行了许多改动，目的是能简化这个mount API，不过这个“简”字的含义对不同的人可能有不同的理解。

新增的moutn API工作是用六七个新的系统调用来替换了此前复杂的mount()系统调用。应用程序可以调用fsopen()来打开某处存放的一个文件系统，或者用fspick()来打开一个已经mount好的文件系统。可以调用fsconfig()来设置这次mount的相关参数。接下来就可以调用fsmount()来在kernel中真正mount这个文件系统，move_mount()则是把mount的结果attach到文件目录树中的某个位置。还有其他一些函数调用实现了相关的一些功能。这组系统调用的主要目的就是能用一组适用性更强、功能更强、更易维护的API来完全替代mount()。

去年11月的时候，Bottomley就提出了这组新API的一个明显问题：无法用它来建立一个read-only bind mount节点。bind mount很特别，它其实并不代表某个真正的文件系统。可以把它们看做是别处已经mount的一个文件系统的另一个查看点。bind mount不会有superblock关联，这样这组新的API就没法用了，因为fsconfig()需要修改superblock。如果针对bind mount调用fsconfig()会导致原有的mount点被修改，这个行为不符合预期。所以没有办法在bind mount的时候设置read-only flag。

David Howells，新增的mount API的作者，他的回答是需要再新加一个mount_setattr()系统调用，用来修改mount的一些属性参数。Bottomley承认这可以解决read-only的问题，不过在其他一些更复杂的情况下还是不够的，比如他在做的UID-shifting bind mount。他认为fsconfig()提供的基于文件描述符的配置机制其实很符合他的需求，不过这个接口需要修改一下来更加通用，希望能覆盖这两种他提出的使用场景。

他在11月份的时候把他建议的接口的初版发了出来，最近又实现了一个更新版本。主要是加了两个新的系统调用：

    int configfd_open(const char *name, unsigned int flags, unsigned int op);
    int configfd_action(int fd, unsigned int cmd, const char *key, void *value,
    			int aux);

调用configfd_open()，会对name参数指定的subsystem打开一个文件描述符，用来修改它的配置。flag参数就是普通的open() 调用中的flag一样的含义。op则定义了是需要新建一个实例来配置，还是直接修改现有的这个实例。configfd_action()则用来对拿到的文件描述符来进行修改。fsconfig()系统调用（当然也包括需要配合使用的fsopen()和fspick()）则利用这对儿新增的函数来重新实现过。Bottomley用mount tmpfs文件系统举了个例子：

    fd = configfd_open("tmpfs", O_CLOEXEC, CONFIGFD_CMD_CREATE);
    configfd_action(fd, CONFIGFD_SET_INT, "mount_attrs", NULL,
		    MOUNT_ATTR_NODEV|MOUNT_ATTR_NOEXEC);
    configfd_action(fd, CONFIGFD_CMD_CREATE, NULL, NULL, 0);
    configfd_action(fd, CONFIGFD_GET_FD, "mountfd", &mfd, O_CLOEXEC);
    move_mount("", mfd, AT_FDCWD, "/mountpoint", MOVE_MOUNT_F_EMPTY_PATH);

configfd_open()调用可以创建一个新的tmpfs实例。第一个configfd_action()调用是用来对这个实例设置nodev和noexec mount flag。第二个configfd_action()调用才真正完成了文件系统的mount动作，第三个configfd_action则是用来获取mount后的文件描述符，用于后面move_mount()的调用，来让这个文件系统最终可见。

Bottomley利用这组代码，也用bind mount的方式重新实现了他的shiftfs filesystem。这个shift bind mount节点收到任何操作的时候都会先对uid和gid加上一个固定偏移量，然后再传递给底层mount过来的文件系统，这个功能主要是希望能在一个user namespace里发起的对底层文件系统时能折算出有真正root权限的访问。

目前只有Christian Brauner一个人回复了一下，他不太喜欢这组patch，认为这里面用了太多的抽象层，还引入了另一个多种功能复用的系统调用，这种设计目前不太讨喜：

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.

Bottomley当然不赞同他的说法。他认为kernel开发中有一种常见的特征：某个subsystem配置起来非常麻烦、但是用起来很容易。文件系统mount就是一个这样的例子，setup的时候很麻烦，不过后面用起来的时候都是通过virtual filesystem接口来轻松使用的。加密秘钥和存储设备也是两个例子。他认为最好能找到一种通用的方式来管理这一类subsystem，而不是每次都创建一组略微跟此前不同的新接口。他认为现在这种configuration file descriptor方式可能就是一个很不错的通用解决方案：

I don't disagree that configuration multiplexors are a user space annoyance, but we put up with them because we get a simple and very generic API for the configured object. Given that they're a necessary evil and a widespread pattern, I think examining the question of whether we could cover them all with a single API and what properties it should have is a useful one.

讨论暂时只到这个程度，目前还很难预测后续会如何达成一致，不过很明显可以看出的一点：如果configfd方案最终无法被kernel接受，那么就需要有人能想出一个新方法来解决configfd所解决的问题。目前来看mailing list中还没有什么更好的方案出现。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～