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

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

[Paul Moore]

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;
>   }

-- 
paul-moore.com

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

[John Johansen]

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;
>>    }
> 

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

[Paul Moore]

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 :)

-- 
paul-moore.com

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

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.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

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?

-- 
paul-moore.com

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

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.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

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.

-- 
paul-moore.com

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]