Hey Paolo, On Fri, Sep 04, 2020 at 10:18:17PM +0200, Paolo Bonzini wrote: > On 04/09/20 21:19, Florian Weimer wrote: > > I'm not sure what the advantage is of returning separate file > > descriptors, and nit operating directly on the pidfd. > > For privilege separation. So far, the common case of pidfd operations > has been that whoever possesses a pidfd has "power" over the target I may misunderstand you but that's actually not quite true. Currently, pidfds are just handles on processes and currently only convey identity. They don't guarantee any sort of privilege over the target process. We have had discussion to treat them more as a capability in the future but that needs to be carefully thought out. > process. Here however we also want to cover the case where one > privileged process wants to set up and manage a memory range for > multiple children. The privilege process can do so by passing the > access file descriptor via SCM_RIGHTS. > > We also want different children to have visibility over different > ranges, which is why there are multiple control fds rather than using > the pidfd itself as control fd. You could have the map/unmap/lock ioctl > on the pidfd itself and the access fd as an argument of the ioctl, but > it seems cleaner to represent the pidfd-mem control capability as its > own file descriptor. We have very much on purpose avoided adding ioctls() on top of pidfds and I'm not fond of the idea of starting to add them. Supporting ioctl()s on an fd usually opens up a can of worms and makes sneaking in questionable features more likely (I'm not saying your patchset does that!). If this interface holds up, I would ask you to please either keep this as a separate fd type or please propose system calls only. Christian
