On Tue, Jun 25, 2024 at 3:09 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > On Tue, 2024-06-25 at 11:10 -0400, Paul Moore wrote: > > On Mon, Jun 24, 2024 at 8:06 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > On Mon, 2024-06-24 at 18:47 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > The patch below does not apply to the 6.6-stable tree. > > > > If someone wants it applied there, or to any other stable or longterm > > > > tree, then please email the backport, including the original git commit > > > > id to <stable@xxxxxxxxxxxxxxx>. > > > > > > > > To reproduce the conflict and resubmit, you may use the following commands: > > > > > > > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y > > > > git checkout FETCH_HEAD > > > > git cherry-pick -x 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34 > > > > # <resolve conflicts, build, test, etc.> > > > > git commit -s > > > > git send-email --to '<stable@xxxxxxxxxxxxxxx>' --in-reply-to '2024062438-shaft-herbicide-4e7d@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. > > > > > > > > Possible dependencies: > > > > > > > > 9a95c5bfbf02 ("ima: Avoid blocking in RCU read-side critical section") > > > > 260017f31a8c ("lsm: use default hook return value in call_int_hook()") > > > > 923831117611 ("evm: Move to LSM infrastructure") > > > > 84594c9ecdca ("ima: Move IMA-Appraisal to LSM infrastructure") > > > > cd3cec0a02c7 ("ima: Move to LSM infrastructure") > > > > 06cca5110774 ("integrity: Move integrity_kernel_module_request() to IMA") > > > > b8d997032a46 ("security: Introduce key_post_create_or_update hook") > > > > 2d705d802414 ("security: Introduce inode_post_remove_acl hook") > > > > 8b9d0b825c65 ("security: Introduce inode_post_set_acl hook") > > > > a7811e34d100 ("security: Introduce inode_post_create_tmpfile hook") > > > > f09068b5a114 ("security: Introduce file_release hook") > > > > 8f46ff5767b0 ("security: Introduce file_post_open hook") > > > > dae52cbf5887 ("security: Introduce inode_post_removexattr hook") > > > > 77fa6f314f03 ("security: Introduce inode_post_setattr hook") > > > > 314a8dc728d0 ("security: Align inode_setattr hook definition with EVM") > > > > 779cb1947e27 ("evm: Align evm_inode_post_setxattr() definition with LSM infrastructure") > > > > 2b6a4054f8c2 ("evm: Align evm_inode_setxattr() definition with LSM infrastructure") > > > > 784111d0093e ("evm: Align evm_inode_post_setattr() definition with LSM infrastructure") > > > > fec5f85e468d ("ima: Align ima_post_read_file() definition with LSM infrastructure") > > > > 526864dd2f60 ("ima: Align ima_inode_removexattr() definition with LSM infrastructure") > > > > > > The patch doesn't apply cleanly due to the '0' in security_audit_rule_init(): > > > return call_int_hook(audit_rule_init, 0, field, op, rulestr, lsmrule); > > > > > > Commit 260017f31a8c ("lsm: use default hook return value in call_int_hook()") > > > removed it. Instead of backporting commit 260017f31a8c, adding the '0' would be > > > simpler. This seems to be the only change needed for linux-6.8.y to 6.4.y. > > > > Agreed. > > > > > For linux-6.3.y to linux-6.2.y, commit b14faf9c94a6 ("lsm: move the audit hook > > > comments to security/security.c") also needs to be applied. > > > > > > Paul, how do you normally handle backports? > > > > Normally I just tag them accordingly and let the stable team handle > > it, with the understanding that the stable team only picks patches > > that have been explicitly marked for stable and not just anything with > > a 'Fixes:' tag. I'm sure you remember when we discussed this > > recently, there shouldn't be anything new here. > > Ok. This should have then been tagged for Stable. Yep, it was. > > The tricky part is what the patch fails to merge automatically. It > > has been my experience that the stable team really doesn't try to do > > any manual merge fixups on the LSM, SELinux, or audit patches, so it > > is really up to me or someone else who cares enough to do the backport > > manually and resubmit. See "option #3" in the stable kernel docs: > > > > * https://docs.kernel.org/process/stable-kernel-rules.html#option-3 > > > > I've personally had some bad experiences working with the stable trees > > (YMMV) which combined with a chronic lack of time means that I rarely > > do a manual backport for the stable trees (the bug needs to be > > especially horrendous). However, others are always free to submit > > backports, see the "option #3" link above. > > Ok. Looks like option 3 is the way to go then. Sounds good. -- paul-moore.com
