Message ID | 20231027130320.69469330@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp300658vqb; Thu, 26 Oct 2023 19:03:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEb16yj9psRsbnuI0MaEIJfWS216kO/NJwT5CpncxTAdWPRhpuqjX31znRAEBLI1FgOjcF4 X-Received: by 2002:a0d:dd0e:0:b0:583:d8d4:7dfe with SMTP id g14-20020a0ddd0e000000b00583d8d47dfemr1259920ywe.31.1698372212602; Thu, 26 Oct 2023 19:03:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698372212; cv=none; d=google.com; s=arc-20160816; b=0JyatUzaq7nJdM/m2iXHfk0GIHRPWOkPlzmWmosAyF+fRSKSO0ScNXYBKXaxq8MXpT jdrDz/eSlZqAaT/g3ZvOhUe/Ar0eBvADa14tTSpQx4vIboJ56OyJFDgkBeDsK9aRbgFw JHIxzjz5GuZeS/1kVUZv9DzHZQ/3zPzEaxGu5Bt1QtuTLaFBfAr42RtMYdFqjQ+l0lrU ILlirfBAsQgL3t1/+plQ8MqOro8XOPueuysVx4YACPUrGMBBDSURoEG9FLlgEmYSWe+I Krf+DxQy/IR/XeZmdPoewX7/1pO8Ue1ck26vkdeZYmE9ym0BFBOVg0I8mUXQ9LA6r4gY c6tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=Xf5W6N69BEL5vs00GlwWRmsDVtQ+vGLCc+Q84wpL6mI=; fh=KgzOqe4McMllxqGlwgacnWMT6tEQsMaRdaCsc71ojTk=; b=pfunLstJg90f4Pa9JBB6SclFbEb1IMecsxYSfAxbBt5FFNBudX/Y4rt/B5xOWMNWzf HdsTocKYI2iNShlTJ/KoluI7kccw2qG7TBoAP6K3R/pbmDB+VOaO6RH2QXkOeJReXctQ Q59Zefv7qP7De6odLPN7d1HmZFnjNAVNU6s8XhjTwllbuXA1k0+WQfwzr5taO/FKbO7r krFkIxxvIfKHiGFOA5negjH1zIgaVHHhbrtOgTSGHdT9EVkaZ/Y5RjWsXCt038I4/DGs tbqsLc592C5SNPRzbKFg4F7rTPrxY4ZKUa3mZmP4rvUiuLyDLIHf9BPZZlgJk6YRpg5M TGxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=uMyv+Gwn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id o128-20020a817386000000b005a247d6f44fsi836121ywc.519.2023.10.26.19.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 19:03:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=uMyv+Gwn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 408BA8274ACA; Thu, 26 Oct 2023 19:03:31 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345132AbjJ0CD2 (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Thu, 26 Oct 2023 22:03:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjJ0CD1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Oct 2023 22:03:27 -0400 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02623AB; Thu, 26 Oct 2023 19:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1698372202; bh=Xf5W6N69BEL5vs00GlwWRmsDVtQ+vGLCc+Q84wpL6mI=; h=Date:From:To:Cc:Subject:From; b=uMyv+GwndA1sIqK17haga7DY6iHQOWflNo0XKSNLpfWoeOcIsD1IKKir4f9yI8V++ W9V3yzmG8cNn9ZMfMcVD4qAy8NnAc3Hu8QYbdLinyUZ0ESN/GEqvWgC7lSmN36UyRf vfpvHwsPvAsKQ0gviH7HBJgcxAyKtJ3zWNEiSpVngvJPgppwJ1z2l6DrGafJFMSrn0 RQ9VePSX6Q8obWbRApWfnQ1ueTxnp157MKyNmiAoU8k0/UiOXP0y22eCLK7aoY+ZFw 1JrCYnjOdsqyYuGCMqBff/MkC5UQ/LJH3fgjx+SMZlaSy2/PreSfZrRMlpD4U5k1BP AyPCCkHSSEgKw== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4SGmCt0nfTz4wby; Fri, 27 Oct 2023 13:03:21 +1100 (AEDT) Date: Fri, 27 Oct 2023 13:03:20 +1100 From: Stephen Rothwell <sfr@canb.auug.org.au> To: John Johansen <john.johansen@canonical.com>, Paul Moore <paul@paul-moore.com> Cc: Casey Schaufler <casey@schaufler-ca.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org> Subject: linux-next: manual merge of the apparmor tree with the security tree Message-ID: <20231027130320.69469330@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/E8NMYd5Jkpz=CO8k/Jo4HbF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 26 Oct 2023 19:03:31 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780872341216844132 X-GMAIL-MSGID: 1780872341216844132 |
Series |
linux-next: manual merge of the apparmor tree with the security tree
|
|
Commit Message
Stephen Rothwell
Oct. 27, 2023, 2:03 a.m. UTC
Hi all, Today's linux-next merge of the apparmor tree got a conflict in: security/apparmor/lsm.c between commit: 3c3bda37ca1d ("AppArmor: Add selfattr hooks") from the security tree and commits: bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data") d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label") from the apparmor 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.
Comments
On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > Today's linux-next merge of the apparmor tree got a conflict in: > > security/apparmor/lsm.c > > between commit: > > 3c3bda37ca1d ("AppArmor: Add selfattr hooks") > > from the security tree and commits: > > bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data") > d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label") > > from the apparmor 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. Thanks Stephen. John, can you take a look and make sure this is correct (it looks okay to me)? > diff --cc security/apparmor/lsm.c > index 5e16c03936b9,4d34180e9799..000000000000 > --- a/security/apparmor/lsm.c > +++ b/security/apparmor/lsm.c > @@@ -771,16 -868,11 +917,16 @@@ out > return error; > > fail: > - aad(&sa)->label = begin_current_label_crit_section(); > + ad.subj_label = begin_current_label_crit_section(); > - ad.info = name; > + if (attr == LSM_ATTR_CURRENT) > - aad(&sa)->info = "current"; > ++ ad.info = "current"; > + else if (attr == LSM_ATTR_EXEC) > - aad(&sa)->info = "exec"; > ++ ad.info = "exec"; > + else > - aad(&sa)->info = "invalid"; > - aad(&sa)->error = error = -EINVAL; > - aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL); > - end_current_label_crit_section(aad(&sa)->label); > ++ ad.info = "invalid"; > + ad.error = error = -EINVAL; > + aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL); > + end_current_label_crit_section(ad.subj_label); > goto out; > }
On 10/28/23 08:32, Paul Moore wrote: > On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: >> >> Hi all, >> >> Today's linux-next merge of the apparmor tree got a conflict in: >> >> security/apparmor/lsm.c >> >> between commit: >> >> 3c3bda37ca1d ("AppArmor: Add selfattr hooks") >> >> from the security tree and commits: >> >> bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data") >> d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label") >> >> from the apparmor 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. > > Thanks Stephen. > > John, can you take a look and make sure this is correct (it looks okay to me)? > yes its good, thanks Stephan. Acked-by: John Johansen <john.johansen@canonical.com> Paul just to double check, to make sure we get ordering on this right 3c3bda37ca1d ("AppArmor: Add selfattr hooks") is part of the Three basic syscalls series, the plan is still to have that series bake in next for a full cycle? Regardless, I will wait until security-ext gets merged to send my pull request, and handle the conflict if its present. >> diff --cc security/apparmor/lsm.c >> index 5e16c03936b9,4d34180e9799..000000000000 >> --- a/security/apparmor/lsm.c >> +++ b/security/apparmor/lsm.c >> @@@ -771,16 -868,11 +917,16 @@@ out >> return error; >> >> fail: >> - aad(&sa)->label = begin_current_label_crit_section(); >> + ad.subj_label = begin_current_label_crit_section(); >> - ad.info = name; >> + if (attr == LSM_ATTR_CURRENT) >> - aad(&sa)->info = "current"; >> ++ ad.info = "current"; >> + else if (attr == LSM_ATTR_EXEC) >> - aad(&sa)->info = "exec"; >> ++ ad.info = "exec"; >> + else >> - aad(&sa)->info = "invalid"; >> - aad(&sa)->error = error = -EINVAL; >> - aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL); >> - end_current_label_crit_section(aad(&sa)->label); >> ++ ad.info = "invalid"; >> + ad.error = error = -EINVAL; >> + aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL); >> + end_current_label_crit_section(ad.subj_label); >> goto out; >> } >
On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote: > On 10/28/23 08:32, Paul Moore wrote: > > On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> > >> Hi all, > >> > >> Today's linux-next merge of the apparmor tree got a conflict in: > >> > >> security/apparmor/lsm.c > >> > >> between commit: > >> > >> 3c3bda37ca1d ("AppArmor: Add selfattr hooks") > >> > >> from the security tree and commits: > >> > >> bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data") > >> d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label") > >> > >> from the apparmor 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. > > > > Thanks Stephen. > > > > John, can you take a look and make sure this is correct (it looks okay to me)? > > > yes its good, thanks Stephan. > > Acked-by: John Johansen <john.johansen@canonical.com> > > Paul just to double check, to make sure we get ordering on this right > 3c3bda37ca1d ("AppArmor: Add selfattr hooks") > > is part of the Three basic syscalls series, the plan is still to have that > series bake in next for a full cycle? Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM syscall patches and I expect the vast majority of these conflicts to disappear, although I'm sure we'll pick up some new ones with the rest of the v6.7-rcX cycle :)
Hi Paul, On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote: > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote: > > > > is part of the Three basic syscalls series, the plan is still to have that > > series bake in next for a full cycle? > > Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM > syscall patches and I expect the vast majority of these conflicts to > disappear, although I'm sure we'll pick up some new ones with the rest > of the v6.7-rcX cycle :) These patches should not be in linux-next until after v6.7-rc1.
On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Paul, > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote: > > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote: > > > > > > is part of the Three basic syscalls series, the plan is still to have that > > > series bake in next for a full cycle? > > > > Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM > > syscall patches and I expect the vast majority of these conflicts to > > disappear, although I'm sure we'll pick up some new ones with the rest > > of the v6.7-rcX cycle :) > > These patches should not be in linux-next until after v6.7-rc1. What if we wanted additional testing beyond the typical? Do you not support that?
Hi all, On Fri, 27 Oct 2023 13:03:20 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Today's linux-next merge of the apparmor tree got a conflict in: > > security/apparmor/lsm.c > > between commit: > > 3c3bda37ca1d ("AppArmor: Add selfattr hooks") > > from the security tree and commits: > > bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data") > d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label") > > from the apparmor 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. > > diff --cc security/apparmor/lsm.c > index 5e16c03936b9,4d34180e9799..000000000000 > --- a/security/apparmor/lsm.c > +++ b/security/apparmor/lsm.c > @@@ -771,16 -868,11 +917,16 @@@ out > return error; > > fail: > - aad(&sa)->label = begin_current_label_crit_section(); > + ad.subj_label = begin_current_label_crit_section(); > - ad.info = name; > + if (attr == LSM_ATTR_CURRENT) > - aad(&sa)->info = "current"; > ++ ad.info = "current"; > + else if (attr == LSM_ATTR_EXEC) > - aad(&sa)->info = "exec"; > ++ ad.info = "exec"; > + else > - aad(&sa)->info = "invalid"; > - aad(&sa)->error = error = -EINVAL; > - aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL); > - end_current_label_crit_section(aad(&sa)->label); > ++ ad.info = "invalid"; > + ad.error = error = -EINVAL; > + aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL); > + end_current_label_crit_section(ad.subj_label); > goto out; > } > This is now a conflict between the security tree and Linus' tree.
Hi Paul, [Sorry for the slow reply] On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@paul-moore.com> wrote: > > On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote: > > > > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote: > > > > > > > > is part of the Three basic syscalls series, the plan is still to have that > > > > series bake in next for a full cycle? > > > > > > Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM > > > syscall patches and I expect the vast majority of these conflicts to > > > disappear, although I'm sure we'll pick up some new ones with the rest > > > of the v6.7-rcX cycle :) > > > > These patches should not be in linux-next until after v6.7-rc1. > > What if we wanted additional testing beyond the typical? Do you not > support that? No, I try hard not to. It just complicates things when I and others have to cope with conflicts and build problems caused by patches/features destined for next+1 while trying to stabilise the current/next release. Sometimes it happens that a feature slips after being added to -next, but please don't do it deliberately.
On Sun, Nov 5, 2023 at 6:14 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Paul, > > [Sorry for the slow reply] > > On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@paul-moore.com> wrote: > > > > On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote: > > > > > > > > > > is part of the Three basic syscalls series, the plan is still to have that > > > > > series bake in next for a full cycle? > > > > > > > > Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM > > > > syscall patches and I expect the vast majority of these conflicts to > > > > disappear, although I'm sure we'll pick up some new ones with the rest > > > > of the v6.7-rcX cycle :) > > > > > > These patches should not be in linux-next until after v6.7-rc1. > > > > What if we wanted additional testing beyond the typical? Do you not > > support that? > > No, I try hard not to. It just complicates things when I and others > have to cope with conflicts and build problems caused by > patches/features destined for next+1 while trying to stabilise the > current/next release. The LSM, SELinux, and audit dev-staging branches will no longer flow into the next branches, and I've reset the current lsm/next branch so this should not be an issue the next time you pull. > Sometimes it happens that a feature slips after being added to -next, > but please don't do it deliberately.
Hi Paul, On Sun, 5 Nov 2023 18:36:49 -0500 Paul Moore <paul@paul-moore.com> wrote: > > The LSM, SELinux, and audit dev-staging branches will no longer flow > into the next branches, and I've reset the current lsm/next branch so > this should not be an issue the next time you pull. Thanks for that. It can all come back after the merge window, of course.
diff --cc security/apparmor/lsm.c index 5e16c03936b9,4d34180e9799..000000000000 --- a/security/apparmor/lsm.c