Re: working-selinuxns rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 26, 2020 at 4:50 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> On Fri, Aug 21, 2020 at 5:00 PM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> >
> > On Thu, Aug 20, 2020 at 9:17 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > >
> > > On Thu, Aug 20, 2020 at 8:10 AM Stephen Smalley
> > > <stephen.smalley.work@xxxxxxxxx> wrote:
> > > > Unfortunately I need to re-base it again and manually fix conflicts
> > > > with my patch to avoid deferencing the policy prior to initialization.
> > > > And I'll need to do it again when/if the patch to convert the policy
> > > > rwlock to rcu lands.  So you might want to wait. I'm starting to
> > > > wonder if the first patch in the series to rename selinux_state/state
> > > > to selinux_ns/ns throughout is a mistake because it produces a lot of
> > > > unnecessary conflicts.  Originally I did it because that was the
> > > > original naming since the encapsulation started to support namespacing
> > > > and then I did a mass rename to selinux_state/state for upstreaming
> > > > since I wasn't yet upstreaming the actual namespace support. Renaming
> > > > it back again reduces conflicts in the later patches but makes the
> > > > first one a pain.  But if I just do a mass rename on all the later
> > > > patches then I can drop the first one and avoid these unnecessary
> > > > conflicts.  Thoughts?
> > >
> > > I agree, the first patch is the one that always causes me the most
> > > pain; considering the work-in-progress state of the patches I think it
> > > would make the most sense to drop that initial cosmetic patch for now
> > > and we can always reinstate it at the end when this work finally
> > > lands.
> >
> > I've made a pass at this and force-pushed it to my
> > working-selinuxns-rebase branch.
> > It turned out that the first patch did two things: it renamed state to
> > ns and it changed all direct references to &selinux_state to use a new
> > current_selinux_state pointer to a static init_selinux_state variable
> > (in preparation for multiple states/namespaces).  I had to retain the
> > latter so I just dropped the renaming part of it, rewrote the
> > description, and did a mass rename in all the subsequent patches back
> > to state. So the first patch may still produce some conflicts but
> > there should be fewer of them.  This is relative to your current next
> > branch but it will need to be manually re-based again when/if the
> > policy rcu patches land, so feel free to wait if you want.  Since
> > every patch required modification and many of them required manual
> > fixups, I dropped all of your Signed-off-by lines and rewrote all of
> > mine with my current preferred email address.
>
> Re-based again on latest next and it was much easier this time around.
> Will need to do it again once Ondrej's patches and my policy_mutex
> patch land but hopefully not too much work.

I'm also considering whether to drop the two patches that were
externally contributed.
The one from James to mark init_selinux_state/ns as ro_after_init
seems kind of pointless; it isn't really used after init except for a
check in the runtime disable code so I don't see any gain from making
it read-only.  The one from Peter to introduce a lockdep class for
what used to be the services (security server) locks is partly
obsoleted by the elimination of the policy rwlock and the description
no longer fits since the status lock got moved up earlier from the
selinux_ss to the selinux_state.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux