Messages in this thread | | | Date | Wed, 18 Mar 2020 10:16:07 +0000 | From | Simon Ser <> | Subject | Re: SO_PEERCRED and pidfd |
| |
On Tuesday, March 17, 2020 7:18 PM, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> 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.
Wouldn't this new mechanism just be an atomic getsockopt+pidfd_open? (It would make sure the process is still alive of course.)
Can you elaborate wrt. capabilities? I'm not sure I understand what that means.
> 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.)
Yeah, this would need to be either a separate SO_* flag or a completely different thing to prevent surprises.
| |