On Wed, 2022-08-24 at 09:56 +0800, Guozihua (Scott) wrote: > On 2022/8/24 9:26, Mimi Zohar wrote: > > On Tue, 2022-08-23 at 21:28 +0800, Guozihua (Scott) wrote: > >> On 2022/8/23 21:21, Mimi Zohar wrote: > >>> On Tue, 2022-08-23 at 16:12 +0800, Guozihua (Scott) wrote: > >>>>> The question is whether we're waiting for the SELinux policy to change > >>>>> from ESTALE or whether it is the number of SELinux based IMA policy > >>>>> rules or some combination of the two. Retrying three times seems to be > >>>>> random. If SELinux waited for ESTALE to change, then it would only be > >>>>> dependent on the time it took to update the SELinux based IMA policy > >>>>> rules. > >>>> > >>>> We are waiting for ima_lsm_update_rules() to finish re-initializing all > >>>> the LSM based rules. > >>> > >>> Fine. Hopefully retrying a maximum of 3 times is sufficient. > >>> > >> Well, at least this should greatly reduce the chance of this issue from > >> happening. > > > > Agreed > > > >> This would be the best we I can think of without locking and > >> busy waiting. Maybe we can also add delays before we retry. Maybe you > >> got any other thought in mind? > > > > Another option would be to re-introduce the equivalent of the "lazy" > > LSM update on -ESTALE, but without updating the policy rule, as the > > notifier callback will eventually get to it. > > > > For this to happen we would need a way to tell when we are able to > continue with the retry though. Previously with the lazy update, on failure security_filter_rule_init() was called before the retry. To avoid locking or detecting when to continue, another option would be to call to security_filter_rule_init() with a local copy of the rule. The retry would be based on a local copy of the rule. Eventually the registered callback will complete, so we don't need to be concerned about updating the actual rules. -- thanks, Mimi
