On Tue, Aug 25, 2020 at 1:21 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote:
>
> 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?
Only reason I can see would potentially be performance overhead of
ebitmap_get_bit(). Probably not significant.
