@Ryan, I've added an SRU justification. Would you mind having a look at it, and in case it's ok uploading this SRU to plucky again?
** Description changed: + SRU Justification: + + [ Impact ] + + * lsblk on an s390x system that uses DASD disks shows no output. + + * journactl shows lsblk is blocked by apparmor: + 2025-04-15T15:02:26.048075+00:00 s5lp1-gen03 kernel: audit: type=1400 + audit(1744729346.034:270): apparmor="DENIED" operation="open" + class="file" profile="lsblk" name="/sys/devices/css0/ + 0.0.0000/0.0.0101/block/dasda/hidden" pid=2070 comm="lsblk" + requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 + + * The reason is that the unprivileged_userns profile does not + have access to /. + + * In case of running lsblk in a container the lsblk command + will even segfault, instead of returning just nothing. + + [ Fix ] + + * unprivileged_userns profile: Allow full file system access + https://gitlab.com/apparmor/apparmor/-/commit/8138bc60d18a7939af766c322586c4268e2940e3 + + [ Test Plan ] + + * Install Ubuntu Server 25.04 on IBM Z in LPAR, z/VM or KVM + using DASD ECKD disks. + + * Please notice that testing this at install time using the installer + shell is not sufficient, since the profile is not active at that time. + + * Ensure util-linux and the s390-tools are installed + (which is by default). + + * Do an lsdasd, it should list DASD ECKD disks, similar to: + $ lsdasd + Bus-ID Status Name Device Type BlkSz Size Blocks + ================================================================================ + 0.0.0200 active dasda 94:0 ECKD 4096 7042MB 1802880 + 0.0.0300 active dasdb 94:4 ECKD 4096 7042MB 1802880 + 0.0.0400 active dasdc 94:8 ECKD 4096 21128MB 5409000 + + * Now execute lsblk (and watch the journal) + + - on a system that is not patched, + one will see no output in the Terminal + (or in case of running in a container a segfault), + and messages like this in the journal: + 2025-04-15T15:02:26.048075+00:00 hwe0006 kernel: audit: type=1400 + audit(1744729346.034:270): apparmor="DENIED" operation="open" + class="file" profile="lsblk" name="/sys/devices/css0/ + 0.0.0000/0.0.0200/block/dasda/hidden" pid=2070 comm="lsblk" + requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 + ... + + - on a patched system, lsblk should provide a proper output + similar to this: + $ lsblk + NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS + loop0 7:0 0 65.4M 1 loop + loop1 7:1 0 65.4M 1 loop /snap/core22/1909 + loop2 7:2 0 39.9M 1 loop + loop3 7:3 0 98.7M 1 loop /snap/lxd/32454 + loop4 7:4 0 39.9M 1 loop /snap/snapd/23776 + loop5 7:5 0 65.4M 1 loop + loop6 7:6 0 100M 1 loop /snap/lxd/33109 + loop7 7:7 0 46.2M 1 loop /snap/snapd/24506 + loop8 7:8 0 65.4M 1 loop /snap/core22/1965 + dasda 94:0 0 20.6G 0 disk + └─dasda1 94:1 0 20.6G 0 part + └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / + dasdb 94:4 0 6.9G 0 disk + ├─dasdb1 94:5 0 1G 0 part /boot + └─dasdb2 94:6 0 5.9G 0 part + └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / + dasdc 94:8 0 20.6G 0 disk + └─dasdc1 94:9 0 20.6G 0 part + └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / + + * (After having done 'aa-disable lsblk' lsblk would also work + would also ork without the profile changes.) + + * As a regression test execute lsblk also on a FCP/SCSP + system, to verify that nothing has changes + (since this was not affected). + + [ Where problems could occur ] + + * The changes in profiles/apparmor.d/unprivileged_userns + are relatively small, just: + - allow file rwlkm /**, + + allow file rwlkm /{,**}, + but expand the prvilidges a bit. + + * Check if apparmor is enabled and the profile active: + sudo aa-status --enabled + sudo aa-status --show=all | grep unprivileged_userns + + * This should not have an impact on other (disk type) devices + like SCSI/FCP, but better check (see test plan, last bullet). + + [ Other Info ] + + * The modification is already included in questing. + + * The patch was tested also successfully tested in plucky on s390x. + + * Since the issue and the tests are very similar in LP#2107455 + and LP#2107402. Hence this SRU justification was added + to both of these two LP bugs. + __________ + Hey, while debugging bug 2107402 we found that there is more to fix. Running lsblk in a container on s390x hits this: [12064869.934674] audit: type=1400 audit(1744791155.353:111962): apparmor="DENIED" operation="file_mmap" class="file" namespace="root//lxd-p_<var-snap-lxd-common-lxd>" profile="lsblk" name="/usr/bin/lsblk" pid=3286747 comm="lsblk" requested_mask="rm" denied_mask="rm" fsuid=1000000 ouid=1000000 To the user it just segfaults. - root@p:~# lsblk Segmentation fault root@p:~# aa-disable lsblk Disabling /usr/bin/lsblk. root@p:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS - loop0 7:0 0 93.8M 1 loop + loop0 7:0 0 93.8M 1 loop loop1 7:1 0 94M 1 l ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2107455 Title: segfault of lsblk s390x in containers due to apparmor Status in Ubuntu on IBM z Systems: Confirmed Status in apparmor package in Ubuntu: Fix Released Bug description: SRU Justification: [ Impact ] * lsblk on an s390x system that uses DASD disks shows no output. * journactl shows lsblk is blocked by apparmor: 2025-04-15T15:02:26.048075+00:00 s5lp1-gen03 kernel: audit: type=1400 audit(1744729346.034:270): apparmor="DENIED" operation="open" class="file" profile="lsblk" name="/sys/devices/css0/ 0.0.0000/0.0.0101/block/dasda/hidden" pid=2070 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 * The reason is that the unprivileged_userns profile does not have access to /. * In case of running lsblk in a container the lsblk command will even segfault, instead of returning just nothing. [ Fix ] * unprivileged_userns profile: Allow full file system access https://gitlab.com/apparmor/apparmor/-/commit/8138bc60d18a7939af766c322586c4268e2940e3 [ Test Plan ] * Install Ubuntu Server 25.04 on IBM Z in LPAR, z/VM or KVM using DASD ECKD disks. * Please notice that testing this at install time using the installer shell is not sufficient, since the profile is not active at that time. * Ensure util-linux and the s390-tools are installed (which is by default). * Do an lsdasd, it should list DASD ECKD disks, similar to: $ lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks ================================================================================ 0.0.0200 active dasda 94:0 ECKD 4096 7042MB 1802880 0.0.0300 active dasdb 94:4 ECKD 4096 7042MB 1802880 0.0.0400 active dasdc 94:8 ECKD 4096 21128MB 5409000 * Now execute lsblk (and watch the journal) - on a system that is not patched, one will see no output in the Terminal (or in case of running in a container a segfault), and messages like this in the journal: 2025-04-15T15:02:26.048075+00:00 hwe0006 kernel: audit: type=1400 audit(1744729346.034:270): apparmor="DENIED" operation="open" class="file" profile="lsblk" name="/sys/devices/css0/ 0.0.0000/0.0.0200/block/dasda/hidden" pid=2070 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 ... - on a patched system, lsblk should provide a proper output similar to this: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 65.4M 1 loop loop1 7:1 0 65.4M 1 loop /snap/core22/1909 loop2 7:2 0 39.9M 1 loop loop3 7:3 0 98.7M 1 loop /snap/lxd/32454 loop4 7:4 0 39.9M 1 loop /snap/snapd/23776 loop5 7:5 0 65.4M 1 loop loop6 7:6 0 100M 1 loop /snap/lxd/33109 loop7 7:7 0 46.2M 1 loop /snap/snapd/24506 loop8 7:8 0 65.4M 1 loop /snap/core22/1965 dasda 94:0 0 20.6G 0 disk └─dasda1 94:1 0 20.6G 0 part └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / dasdb 94:4 0 6.9G 0 disk ├─dasdb1 94:5 0 1G 0 part /boot └─dasdb2 94:6 0 5.9G 0 part └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / dasdc 94:8 0 20.6G 0 disk └─dasdc1 94:9 0 20.6G 0 part └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm / * (After having done 'aa-disable lsblk' lsblk would also work would also ork without the profile changes.) * As a regression test execute lsblk also on a FCP/SCSP system, to verify that nothing has changes (since this was not affected). [ Where problems could occur ] * The changes in profiles/apparmor.d/unprivileged_userns are relatively small, just: - allow file rwlkm /**, + allow file rwlkm /{,**}, but expand the prvilidges a bit. * Check if apparmor is enabled and the profile active: sudo aa-status --enabled sudo aa-status --show=all | grep unprivileged_userns * This should not have an impact on other (disk type) devices like SCSI/FCP, but better check (see test plan, last bullet). [ Other Info ] * The modification is already included in questing. * The patch was tested also successfully tested in plucky on s390x. * Since the issue and the tests are very similar in LP#2107455 and LP#2107402. Hence this SRU justification was added to both of these two LP bugs. __________ Hey, while debugging bug 2107402 we found that there is more to fix. Running lsblk in a container on s390x hits this: [12064869.934674] audit: type=1400 audit(1744791155.353:111962): apparmor="DENIED" operation="file_mmap" class="file" namespace="root//lxd-p_<var-snap-lxd-common-lxd>" profile="lsblk" name="/usr/bin/lsblk" pid=3286747 comm="lsblk" requested_mask="rm" denied_mask="rm" fsuid=1000000 ouid=1000000 To the user it just segfaults. root@p:~# lsblk Segmentation fault root@p:~# aa-disable lsblk Disabling /usr/bin/lsblk. root@p:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 93.8M 1 loop loop1 7:1 0 94M 1 l ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2107455/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
