Bug 2025264

I think this is a bug in snap-device-helper. Let me try to fix that upstream and backport a patch if needed.

FEDORA-2021-bbc6ea4640 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-bbc6ea4640

FEDORA-2021-3af8be56fc has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3af8be56fc

FEDORA-2021-bbc6ea4640 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-bbc6ea4640`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-bbc6ea4640

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-3af8be56fc has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3af8be56fc`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3af8be56fc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I installed snapd-2.53.2-2.fc35.x86_64 and it still fails:



Nov 30 07:27:44 mybox systemd-udevd[2118]: lp0: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/usbmisc/lp0 180:0' failed with exit code 1.
Nov 30 07:27:44 mybox systemd-udevd[2118]: lp0: Process '/usr/libexec/snapd/snap-device-helper add snap_ghostscript-printer-app_ghostscript-printer-app-server /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/usbmisc/lp0 180:0' failed with exit code 1.


stracing the device helper gives the following showing permission error on the "bpf" system call.



readlink("//sys//devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/usbmisc/lp0/subsystem", "../../../../../../../../class/usbmisc", 4096) = 37
statfs("/sys/fs/cgroup", {f_type=CGROUP2_SUPER_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NODEV|ST_NOEXEC|ST_RELATIME}) = 0
prlimit64(0, RLIMIT_MEMLOCK, NULL, {rlim_cur=64*1024, rlim_max=64*1024}) = 0
getegid()                               = 0
setresgid(-1, 0, -1)                    = 0
getegid()                               = 0
prlimit64(0, RLIMIT_MEMLOCK, {rlim_cur=512*1024, rlim_max=512*1024}, NULL) = 0
getegid()                               = 0
setresgid(-1, 0, -1)                    = 0
getegid()                               = 0
getegid()                               = 0
setresgid(-1, 0, -1)                    = 0
getegid()                               = 0
mkdir("/sys/fs/bpf/snap", 0700)         = -1 EEXIST (File exists)
bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/snap/snap_ghostscript-printer-app_ghostscript-printer-app-server", bpf_fd=0, file_flags=0}, 128) = -1 EPERM (Operation not permitted)
getegid()                               = 0
setresgid(-1, 0, -1)                    = 0
getegid()                               = 0
write(2, "cannot get existing device map", 30) = 30
write(2, ": Operation not permitted\n", 26) = 26
exit_group(1)                           = ?
+++ exited with 1 +++

Did you run snap-device-helper yourself or was it invoked by udev? Is SELinux running in enforcing mode? Can you check for denials? `ausearch -m AVC`.

(In reply to Maciek Borzecki from comment #7)
> Did you run snap-device-helper yourself or was it invoked by udev? Is
> SELinux running in enforcing mode? Can you check for denials? `ausearch -m
> AVC`.

I started strace on the systemd-udevd process

   strace -o /var/tmp/udev -ff -s2000 -p <the pid of the systemd-udevd process>

Then turn on my usb printer.

SELinux is permanently running in permission mode;  to many denials otherwise.

Oh wow, this is fun. So it's blocked by systemd setting up syscall filtering for udev. By default only syscall sets in @system-service @module @raw-io are allowed, bpf() is not part of those sets.

Adding an override like this makes the problem go away:

# /etc/systemd/system/systemd-udevd.service.d/override.conf
[Service]
SystemCallFilter=bpf

At this point it's no longer snapd issue. I'll see if I can get this fixed upstream.

Filed RHBZ#2027627 for systemd and proposed a fix in systemd upstream. Let's see how that foges.

(In reply to Maciek Borzecki from comment #10)
> Filed RHBZ#2027627 for systemd and proposed a fix in systemd upstream. Let's
> see how that foges.

https://github.com/systemd/systemd/pull/21576/commits/2a83a80c1294edd0b75bd40943e62796e257ac8b

FEDORA-2021-3af8be56fc has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-bbc6ea4640 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Hello,

I don't know if that is the same issue. On my system, the logs are full of lines such as (taking spotify as an example):

card0: Process '/usr/libexec/snapd/snap-device-helper add snap_spotify_spotify /devices/platform/simple-framebuffer.0/drm/card0 226:0' failed with exit code 1.
card0-Unknown-1: Process '/usr/libexec/snapd/snap-device-helper add snap_spotify_spotify /devices/platform/simple-framebuffer.0/drm/card0/card0-Unknown-1 0:0' failed with exit code 1.
card0-Unknown-1: Process '/usr/libexec/snapd/snap-device-helper remove snap_spotify_spotify /devices/platform/simple-framebuffer.0/drm/card0/card0-Unknown-1 0:0' failed with exit code 1.
card0: Process '/usr/libexec/snapd/snap-device-helper remove snap_spotify_spotify /devices/platform/simple-framebuffer.0/drm/card0 226:0' failed with exit code 1.
card1: Process '/usr/libexec/snapd/snap-device-helper add snap_spotify_spotify /devices/pci0000:00/0000:00:02.0/drm/card1 226:1' failed with exit code 1.
card1-DP-1: Process '/usr/libexec/snapd/snap-device-helper add snap_spotify_spotify /devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1 0:0' failed with exit code 1.

Same for card1-DP-2, card1-HDMI-A-1, etc.

Should I open a new bug report? That does not seem to cause any further issues. Or would that be linked to the confinement?