Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1d0b80d272a8e8c4a7b322d2d2bcc483d9e41a28.camel@btinternet.com>
Subject: Re: linux-next: manual merge of the selinux tree with the keys tree
From:   Richard Haines <richard_c_haines@btinternet.com>
To:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Paul Moore <paul@paul-moore.com>,
        David Howells <dhowells@redhat.com>, sds@tycho.nsa.gov
Cc:     Linux Next Mailing List <linux-next@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Christian =?ISO-8859-1?Q?G=F6ttsche?= <cgzones@googlemail.com>,
        Stephen Smalley <sds@tycho.nsa.gov>
Date:   Wed, 12 Feb 2020 12:03:33 +0000
In-Reply-To: <20200212103548.266f81fd@canb.auug.org.au>
References: <20200212103548.266f81fd@canb.auug.org.au>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 2020-02-12 at 10:35 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the selinux tree got conflicts in:
> 
>   security/selinux/include/security.h
>   security/selinux/ss/services.c
> 
> between commit:
> 
>   87b14da5b76a ("security/selinux: Add support for new key
> permissions")
> 
> from the keys tree and commit:
> 
>   7470d0d13fb6 ("selinux: allow kernfs symlinks to inherit parent
> directory context")
> 
> from the selinux tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.
> 

I think 87b14da5b76a ("security/selinux: Add support for new key
permissions") should be revoked and resubmitted via selinux as it was
never ack'ed there and produced before 7470d0d13fb6 ("selinux: allow
kernfs symlinks to inherit parent directory context"), that has been
ack'ed.

Because of this the policy capability ids are out of sync with what has
been committed in userspace libsepol.

Plus as Paul mentioned there is an outstanding query on the permission
loop that David needs to answer.