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

["Christian König" <christian.koenig@amd.com>]

On 3/26/26 15:42, Christian Brauner wrote:
> 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@amd.com>
>>>>>> ---
>>>>>
>>>>> 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.

What exactly do you mean with that? As far as I can see we can't expose per file descriptor information through netlink.

What's actually the problem exposing things through fdinfo? As far as I can see it shouldn't be much of a problem exposing the directory for everybody and letting each file decide what the security checks should be.

Regards,
Christian.