Messages in this thread | | | Date | Tue, 17 Mar 2020 19:18:43 +0100 | From | Christian Brauner <> | Subject | Re: SO_PEERCRED and pidfd |
| |
On Tue, Mar 17, 2020 at 05:54:47PM +0000, Simon Ser wrote: > Hi all, > > I'm a Wayland developer and I've been working on protocol security, > which involves identifying the process on the other end of a Unix > socket [1]. This is already done by e.g. D-Bus via the PID, however > this is racy [2]. > > Getting the PID is done via SO_PEERCRED. Would there be interest in > adding a way to get a pidfd out of a Unix socket to fix the race?
Puh, I knew this would happen. I've been asked to add this feature by the systemd people as well and also at a conference last year. And honestly, I don't know yet. pidfds right now are mostly about guaranteeing (stable) identity and they come with the necessary restrictions in place to prevent shenanigans (such as signaling across pid namespaces a restriction I'd like to lift at _some_ point). But I have been thinking about attaching some capability like features to pidfds soon as that has been an even more frequent request. At that point having them receivable this way might be problematic unless we put restrictions in place.
I would like to go through codepaths for SO_PEERCRED as I don't have them in my head and so can't really say something definitely about this just now. (From the top of my head it seems that if we were to do this it might need to be a separate SO_* flag? Mainly so people don't suddenly receive fds they didn't expect.)
Christian
| |