On Wed, May 6, 2020 at 10:27 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Wed, May 6, 2020 at 3:57 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Wed, May 6, 2020 at 3:37 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > > > On Wed, May 6, 2020 at 2:54 AM Stephen Smalley > > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > diff --git a/policy/Makefile b/policy/Makefile > > > > index dfe601b..f86aac4 100644 > > > > --- a/policy/Makefile > > > > +++ b/policy/Makefile > > > > @@ -40,6 +40,8 @@ CIL_TARGETS = test_add_levels.cil test_glblub.cil > > > > endif > > > > endif # GLBLUB > > > > > > > > +CIL_TARGETS += test_mlsconstrain.cil test_overlay_defaultrange.cil > > > > > > This causes a problem on RHEL-6, since it doesn't understand CIL > > > modules. We'll probably need to detect if semodule supports CIL before > > > trying to add the modules. > > > > I thought we had stopped worrying about RHEL compatibility in the > > upstream testsuite going forward and deferring all of those tweaks to > > downstream? I'm not fundamentally opposed but that was the impression > > I had received earlier. If we are still carrying RHEL support, then > > how old of RHEL do we still care about? RHEL-6 is six months away > > from regular EOL? I'd still like to keep compatibility with at least RHEL-6+ (with older versions approaching EOL being less important than newer ones) at least where it can be achieved easily (without too intrusive changes). > > Also not sure what we would test here to determine whether CIL is supported. > It isn't directly linked to a particular kernel or module binary > policy version, and the version of libsepol that first introduced it > in RHEL-7 probably differs from upstream (assuming it was back-ported > there). Hm... yes, I sent the email late in the evening and hadn't given it proper thought. I agree this would be too much trouble for little gain. -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
