25.04.2024 12:54, Christian Brauner пишет:
I'm not sure what you don't understand or why you need further clarification. Your patch allows any opener using your new flag to steal the uid/gid/whatever from the original opener.
No, absolutely impossible (see below).
It was even worse in the first version where the whole struct cred of the original opener was used. It's obviously a glaring security hole that's opened up by this.
Well, it was the second version actually (first one only had fsuid/fsgid), but no, its the same thing either way. The creds are overridden for a diration of an openat2() syscall. It doesn't matter what uid/gid are there, because they are not used during openat2(), and are reverted back at the end. The only reason I decided to get back to fsuid/fsgid, were the capabilities, which I don't want to be raised during openat2().
Let alone that the justification "It's useful for some lightweight sandboxing" is absolutely not sufficient to justify substantial shifts in the permission model. The NAK stands.
But I am sure you still don't understand what exactly the patch does, so why not to ask instead of asserting? You say uid/gid can be stolen, but no, it can't: the creds are reverted. Only fsuid/fsgid (and caps in v2 of the patch) actually affect openat2(), but nothing is "leaked" after openat2() finished. That said, Viro already pointed to the actual problem, and the patch-testing bot did the same. So I have a valid complains already, and you don't have to add the invalid ones to them. :)
