Re: [RFC PATCH] fdinfo: Option for public fdinfo

[Christian Brauner]

On Tue, Mar 24, 2026 at 10:30:26AM +0100, Christian König wrote:
> On 3/24/26 09:53, Christian Brauner wrote:
> > On Mon, Mar 23, 2026 at 02:16:59PM +0100, Christian König wrote:
> >> On 3/23/26 13:13, Christian Brauner wrote:
> >>> On Mon, Mar 16, 2026 at 02:38:28PM -0400, David Francis wrote:
> >>>> We want some GPU information to be publicly available to all
> >>>> processes for basic system-wide profiling (think GPU versions
> >>>> of top).
> >>>>
> >>>> This information is available in fdinfo and not easily exposed
> >>>> by other interfaces.
> >>>>
> >>>> Add fd_op flag FOP_PUBLIC_FDINFO, which, if set, makes the fdinfo
> >>>> for that file available to read for processes without ptrace
> >>>> permissions.
> >>>>
> >>>> Note that this makes public how many files each process has open,
> >>>> and what their fds are.
> >>>>
> >>>> Signed-off-by: David Francis <David.Francis@xxxxxxx>
> >>>> ---
> >>>
> >>> Eew, please let's not. Add an ioctl if you need to be able to retrieve
> >>> that info.
> >>
> >> Yeah the problem is an IOCTL is even worse from the security pov.
> >>
> >> This is for an tool which doesn't have access to the file descriptor which provides that information.
> >>
> >> So using pidfd_getfd() or similar to get the FD and then call an IOCTL on it would be a security violation.
> >>
> >> The real question is how should we make this information public available in the system?
> > 
> > Don't you have a way to make this info available in sysfs? Just like
> > networking exposes info about network devices in there that may come and
> > go?
> 
> Yeah that was already tried as well and Greg summarized it as "sometimes you don't know how horrible something is until you tried it".
> 
> So the memory accounting parts for DMA-buf files in sysfs were deprecated and removed again just a few weeks ago. And that was basically just a subset of what David tries to do here.
> 
> The requirement is that you want to be able to access the stats for accelerators/GPUs drivers similar to how tools like "top" or "htop" work. E.g. everybody can access /proc/*/stat as well, it's just that some security related information are left out.
> 
> As far as I can see we have only a couple of different options to fulfill that requirement and lowering the security for fdinfo like David's patch here suggests still looks like the most defensive one to me.

It's not acceptable to make /proc/<pid>/fdinfo accessible just to carve
out an exception for you. You can look at implementing something like
taskstats based on netlink transpart if you want to.