Comment 3 for bug 1967884

The fsetid is actually quite old (at least 3 years; there may have been a Trello card for it). At one point it came in and I did analysis and tweaked the order of the priv dropping in snap-confine to get rid of it. Then some stuff was added to snap-confine and it came back. I always had it as a to-do to work through it, but weighing the necessity of keeping the priv-dropping solid vs getting rid of the noisy denial always kept it on the back-burner.

Bottom line, the fsetid has to do with the delicate drop/raise/.../full drop dance we do and isn't new. I think you should keep that separate from these other two.

The new ones feel like it's a parent/child issue with the new kernel (ie where it depends on what is launching snap-confine/what snap-confine is launching), but maybe it is just as simple as the 5.15 kernel has new capabilities checks for things it didn't before.

When looking at this, remember that the kernel rate limits capability denials differently than say, file rules and that it can be difficult to trigger the denials reliably without taking additional steps. John can help you with these techniques. I recall wanting to pull my hair out when investigating the fsetid denial until I nailed down how to get the logged denial reliably :)