On Fri, Nov 5, 2021 at 1:41 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > William ML Leslie, le ven. 05 nov. 2021 21:18:50 +1100, a ecrit: > > > which makes the root filesystem reauthenticate all of the > > > processes file descriptors. > > > > It seems to eliminate a rather convenient method of delegation; a > > process opening a descriptor, forking and executing a child, and > > dropping privileges, while retaining access to that one resource. > > reauthenticating doesn't mean closing. File permissions for open are > checked at the open step, not later on. But then there are other things > than just opening a file, such as starting a translator, which we don't > necessarily want to let the unprivileged-with-one-opened-file do.
If I may add to what Samuel has said... The Hurd is a capability system, but not a *pure* capability system: it implements Unix semantics on top of Mach/capabilities. File descriptors, exec, setuid, etc. are all Unix concepts. And in a Unix system, you definitely expect that a change in a process' authority applies to things like which files it is allowed to open through a file descriptor that refers to a directory, which is why all the file descriptors have to be reauthenticated when the auth changes. The file descriptor table is really meant to hold I/O objects, not arbitrary ports; and I/O objects are expected to behave in a predictable way when reauthenticated: you keep access to the object, but the object reconsiders what further things you can do to it / access through it, according to your new authority. As another example, you can open a device while you have root access, then drop privileges; you'll still be able to read or write the file descriptor, but you won't be able to fchown/file_chown it. If you ignore the Unix personality of the system, you can indeed pass any ports to an otherwise unprivileged task, but you better do it outside of the file descriptors table. The Mach mechanisms for that are the bootstrap port and mach_ports_register (). Sergey