[RFC PATCH] selinux: deprecate disabling SELinux and runtime

[Paul Moore]

On Fri, Jan 3, 2020 at 4:32 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> On Thu, Jan 2, 2020 at 10:38 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Thu, Jan 2, 2020 at 4:24 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> > > On Thu, Dec 19, 2019 at 8:22 PM Paul Moore <paul at paul-moore.com> wrote:
> > > > Deprecate the CONFIG_SECURITY_SELINUX_DISABLE functionality ...

...

> > > Looks reasonable, informal ACK from me.
> >
> > Thanks.  You want to make that a formal ACK? ;)
>
> Sure, if you find it useful :)
>
> Acked-by: Ondrej Mosnacek <omosnace at redhat.com>

Yes, it is useful, thank you.

For this patch your ACK is particularly significant because you are
representing RH here (I'm assuming you are still the RH SELinux kernel
person) and we are deprecating a feature used by Fedora.  In my
opinion it would be a mistake to merge a deprecation patch without the
ACKs of those who rely on the feature targeted for removal (although
in some cases it may need to be done regardless).

I also really dislike merging my own patches without at least one
other Acked-by/Reviewed-by tag for the simple reason that I believe
every patch should have at least two people (author and at least one
reviewer) who agree that the patch is reasonable.  Of course there are
exceptions for trivial and critical fixes, e.g. 15b590a81fcd
("selinux: ensure the policy has been loaded before reading the sidtab
stats"), but I like to keep those as the exception rather than the
rule.  Just because someone is listed in the MAINTAINERS file
shouldn't mean they are exempt from the normal review process.

Generally speaking, one of the more useful things one can do from an
upstream perspective is to review and test patches that are submitted
to the list.  We are a community driven project after all, and the
community aspect shouldn't be limited to just the development of
patches ;)

-- 
paul moore
www.paul-moore.com