** 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
+ * The reason is that the lsblk profile does not allow access
+ to /sys/devices/css0.
[ 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
+ 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
+ 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 /
-
+ 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.)
+ would also work without the profile changes.)
- * As a regression test execute lsblk also on a FCP/SCSP
- system, to verify that nothing has changes
+ * As a regression test, execute lsblk also on a FCP/SCSP
+ system, to verify that nothing has changed
(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.
-
+ * This SRU loosens confinement on the lsblk profile. However, if a user
+ manually modified the installed profiles, then the package upgrade would
+ cause conflicts, and rejection of the incoming changes (either by hand
+ during an interactive upgrade or automatically during an batch unattended
+ upgrade) would result in end users not getting the packaged fix.
+
* Check if apparmor is enabled and the profile active:
sudo aa-status --enabled
- sudo aa-status --show=all | grep unprivileged_userns
-
+ sudo aa-status --show=all | grep lsblk
+
* 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
...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2107455
Title:
segfault of lsblk s390x in containers due to apparmor
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2107455/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
