On Sun, May 23, 2021 at 07:43:16AM -0700, Andi Kleen wrote:
On 5/23/2021 12:31 AM, John Wood wrote:
Hi,
On Fri, May 21, 2021 at 11:02:14AM -0700, Andi Kleen wrote:
Moreover, I think this solves another problem pointed out by Andi Kleen during the v5 review [2] related to the possibility that a supervisor respawns processes killed by the Brute LSM. He suggested adding some way so a supervisor can know that a process has been killed by Brute and then decide to respawn or not. So, now, the supervisor can read the brute xattr of one executable and know if it is blocked by Brute and why (using the statistical data).
It looks better now, Thank.
One potential problem is that the supervisor might see the executable directly, but run it through some wrapper. In fact I suspect that will be fairly common with complex daemons. So it couldn't directly look at the xattr. Might be useful to also pass this information through the wait* chain, so that the supervisor can directly collect it. That would need some extension to these system calls.
Could something like this help? (not tested)
This works even when someone further down the chain died?
Yes, this is the idea. (but now is a work in progress :) )
Assuming it does, for SIGCHLD it seems reasonable.
So, if there are no objections I will work on it for the next version.
I'm not fully sure how it will interact with cgroup release tracking though, that might need more research (my understanding is that modern supervisors often use cgroups)
Yeah, a new topic to learn: cgroups. I will try to work on this too if there are no objections.
Thanks for the feedback. John Wood