Keyboard/mouse input not working on 22.10 (and missing AppArmor info)

snapd
1

Hi, we recently realized that USB / HID input on 22.10 doesn’t work… on some hardware. Using --devmode makes it work, as does adding this to the snap’s profile:

/sys/dev/char/* r

Part of the problem is that there are no mentions of any relevant DENIED access:

[10675.379585] audit: type=1400 audit(1665575274.212:10802): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/meta/snap.yaml" pid=75369 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.381222] audit: type=1400 audit(1665575274.212:10803): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/cups/" pid=75369 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.381865] audit: type=1400 audit(1665575274.216:10804): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75369 comm="run-shell" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.383543] audit: type=1400 audit(1665575274.216:10805): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75394 comm="id" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.385849] audit: type=1400 audit(1665575274.220:10806): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/meta/snap.yaml" pid=75395 comm="snapctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.392117] audit: type=1400 audit(1665575274.224:10807): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/meta/snap.yaml" pid=75400 comm="snapctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.397535] audit: type=1400 audit(1665575274.228:10808): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75406 comm="dirname" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.398976] audit: type=1400 audit(1665575274.232:10809): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75407 comm="mkdir" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.400364] audit: type=1400 audit(1665575274.232:10810): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75408 comm="mkdir" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[10675.401961] audit: type=1400 audit(1665575274.236:10811): apparmor="DENIED" operation="getattr" class="file" profile="snap.confined-shell.confined-shell" name="/var/lib/snapd/void/" pid=75369 comm="miriway" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

It doesn’t help to pinpoint what’s the particular problematic path. The difference between --strace runs show that it tries to openat() vs. lstat() some devices under this path:

# broken
[pid 233672] openat(AT_FDCWD, "/sys/dev/char/226:0/device/uevent", O_RDONLY) = 12
[pid 233672] openat(AT_FDCWD, "/sys/dev/char/226:0/device/vendor", O_RDONLY) = 12
[pid 233672] openat(AT_FDCWD, "/sys/dev/char/226:0/device/device", O_RDONLY) = 12
[pid 233672] openat(AT_FDCWD, "/sys/dev/char/226:0/device/subsystem_vendor", O_RDONLY) = 12
[pid 233672] openat(AT_FDCWD, "/sys/dev/char/226:0/device/subsystem_device", O_RDONLY) = 12
[pid 233672] stat("/sys/dev/char/226:128/device/drm", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 233672] readlink("/sys/dev/char/226:128/device/subsystem", "../../../bus/pci", 4096) = 16

vs.

# working
[pid 232840] lstat("/sys/dev/char", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 232840] lstat("/sys/dev/char/226:0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
[pid 232840] readlink("/sys/dev/char/226:0", "../../devices/pci0000:00/0000:00"..., 4095) = 47
[pid 232840] lstat("/sys/dev/char", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 232840] lstat("/sys/dev/char/226:0", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0

To reproduce, just run ubuntu-frame from a TTY (make sure to have SSH access as you’ll need to kill it afterwards, it not getting any input). You should see a cursor moving when moving your pointer device - but you won’t - unless you add the above bit to the profile.

It looks as if something between libinput and the kernel changed on 22.10, that doesn’t affect some hardware (Intel 12th Gen seems to be working). But the worst part is we’re not getting any info on opening it up in a more surgical way than the above.

EDIT:

For clarity, input is provided by the wayland slot:

Frame happens to also have hardware-observe to silence libinput spamming the logs with DENIEDs on non-input devices, but that doesn’t seem to matter.

1 Like
2

@alexmurray @mvo this :point_up_2: is what I’m having trouble with.

3

What is odd about that AppArmor rule is that (from what I can see) /sys/dev/char is full of symlinks - but AppArmor mediates the real path that a symlink points to - so perhaps it may be enough just to be able to list the contents of /sys/dev/char to get this working - ie an AppArmor rule like:

/sys/dev/char/ r,

If so, I think it would be appropriate to add this to the wayland interface if it is now required by libinput.

4

I too saw this problem when it was posted. But I can no longer reproduce

5

@alexmurray thanks for that, if we ever get bugged by this again we’ll try this.

Would a folder listing not show up as a DENIED? Should it? Shall I file a bug?

EDIT: At least ls /sys/dev/char does log the denial.

:ghost:-bug, then.