Lennart Poettering

> CheckAuthorization(pidfd) Sorry, but I hope noone ever does that, that's simply not safe. you cannot safely derive a UID from that, which makes this useless for authentication. We should...

> case the rule doesn't check for NoNewPrivs i am sorry what? rules check for NNP? how is that safe? you cannot atomically check NNP and other process creds, hence...

> The crucial thing is, building the subject is not the same as authorizing it. As the code comment linked above describes, and as the many CVEs in this area...

> Apart from the fact that, as already said, you can pass the uid together with the pidfd just fine if you want to - why would that be unsafe,...

> > I am sorry, but please provide an example what kind of attack that passing just a pidfd to a peer is going to block that passing uid+pid+starttime is...

> I didn't go through the effort of weaving pid fd support through it just for the lolz. I've added this API upstream especially for your use case. I don't...

> It is helpful because it proves that you cannot uniquely identify a process even if you have the full tuple. Adding the uid is a workaround that reduces the...

> > > > This PR relies on SO_PEERPIDFD which is also only available in the very latest kernel anyway, so it requires a new distro release anyway my off-the-shelf...

> No, it is most definitely not enough, as it still doesn't uniquely identify anything, it only tells you that it comes from the same session. That is not good...

So I found this now: https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/src/polkitbackend/polkitbackendjsauthority.cpp?ref_type=heads#L623 Which I guess is what you added there. While I think this information is useful to improve logging and things, it's not useful for...