diff mbox series

linux-next: manual merge of the apparmor tree with the security tree

Message ID 20231027130320.69469330@canb.auug.org.au
State New
Headers
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

Paul Moore Oct. 28, 2023, 3:32 p.m. UTC | #1 
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;
>   }
John Johansen Oct. 29, 2023, 9:09 p.m. UTC | #2 
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;
>>    }
>
Paul Moore Oct. 30, 2023, 4:52 p.m. UTC | #3 
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 :)
Stephen Rothwell Oct. 30, 2023, 8:46 p.m. UTC | #4 
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.
Paul Moore Oct. 30, 2023, 9:04 p.m. UTC | #5 
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?
Stephen Rothwell Nov. 5, 2023, 11:09 p.m. UTC | #6 
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.
Stephen Rothwell Nov. 5, 2023, 11:14 p.m. UTC | #7 
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.
Paul Moore Nov. 5, 2023, 11:36 p.m. UTC | #8 
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.
Stephen Rothwell Nov. 6, 2023, 12:28 a.m. UTC | #9 
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 mbox series

Patch

diff --cc security/apparmor/lsm.c
index 5e16c03936b9,4d34180e9799..000000000000
--- a/security/apparmor/lsm.c