On Tue, Aug 25, 2020 at 6:07 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> On Tue, Aug 25, 2020 at 11:20 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote:
> >
> > After the RCU conversion, it is possible to simply check the policy
> > pointer against NULL instead.
> >
> > Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx>
> > ---
>
> > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> > index ec4570d6c38f7..d863b23f2a670 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -2221,20 +2218,19 @@ void selinux_policy_commit(struct selinux_state *state,
> > /* Load the policycaps from the new policy */
> > security_load_policycaps(state, newpolicy);
> >
> > - if (!selinux_initialized(state)) {
> > + if (!oldpolicy) {
> > /*
> > * After first policy load, the security server is
> > * marked as initialized and ready to handle requests and
> > * any objects created prior to policy load are then labeled.
> > */
> > - selinux_mark_initialized(state);
> > selinux_complete_init();
>
> This isn't quite equivalent. The difference is whether
> security_load_policycaps() has completed. Not sure of the
> implications but could yield different behavior.
Good point... And you just reminded me of my plan to eliminate the
selinux_state::policycap[] array and replace it with calls to
security_policycap_supported(). That should have no more race
conditions than the current code at least... I'll try to splice such a
patch below this one for the next revision. Or is there some
compelling reason to keep the array?
--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
