A new API for mounting filesystems
A new API for mounting filesystems
Posted Apr 3, 2017 18:43 UTC (Mon) by droundy (subscriber, #4559)In reply to: A new API for mounting filesystems by fishface60
Parent article: A new API for mounting filesystems
However, it seems like you'd effectively be implementing a second version of mount namespaces, which while possibly elegant doesn't actually sound like a great idea. :(
If I were to redesign linux (which I won't be doing for many good reasons) I'd be highly tempted to remove all the non-"at" system calls, and move the whole concept of the root directory and working directory into user space (as two file descriptors). Things would be simpler and more elegant, and we wouldn't need special system calls like `chdir` or `pivot_root`. But that's only a daydream...
Posted Apr 3, 2017 19:27 UTC (Mon)
by josh (subscriber, #17465)
[Link] (1 responses)
Agreed completely for working directory. File-descriptor inheritance seems quite appropriate for that.
For the root directory, that would raise some security implications. Any setuid/setgid/privilege-raising application would need a secure way of running/loading out of its own root, so it can't get fooled by being run within a custom root. Otherwise, you could trivially use that to become root by running a setuid program with a root that contained your own dynamic libraries.
As long as we're talking about fundamental redesigns, I'd also eliminate all "raise privilege when run" mechanisms, and instead require handling that in userspace. Make a user/group privilege something you can have 0 or more of, with the privilege token for root giving you the ability to mint more such tokens. And then handle sudo/su/etc by running a server in userspace that can spawn more privileged processes on behalf of less privileged processes given appropriate controls.
Posted Apr 4, 2017 14:00 UTC (Tue)
by jugglerchris (guest, #114208)
[Link]
A new API for mounting filesystems
A new API for mounting filesystems