Providing wider access to bpf()

Posted Jun 27, 2019 21:36 UTC (Thu) by josh (subscriber, #17465)
Parent article: Providing wider access to bpf()

It seems odd to me that you open this device and run an ioctl to get permission, rather than opening this device and passing the file descriptor as a handle to the calls you want to make.

Providing wider access to bpf()

Posted Jun 27, 2019 23:02 UTC (Thu) by luto (guest, #39314) [Link] (2 responses)

Indeed. If the descriptor is a capability, it seems that it should be used as such.

Also, some of those capable() calls control the ability to convert pointers to integers. Those should not be changed.

Providing wider access to bpf()

Posted Jun 27, 2019 23:30 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

I like the approach you proposed in Portland; any plans to pursue that for this case?

Providing wider access to bpf()

Posted Jun 27, 2019 23:50 UTC (Thu) by luto (guest, #39314) [Link]

I emailed about that on the patch thread.

I think it’s the wrong approach here. People are obviously willing to slightly modify their program for this new unprivileged mode — the ioctl requires it. Given that, I think the right solution is to be fully explicit: just pass the fd into the bpf() syscall.