> Before closing the bugs, could you confirm that you are running > SELinux in permissive mode or not (for what I can see in the > logs > it seems to be the case)? > Yes, it's running in permissive mode, I'm still working on getting the policy right. > On one of my machine at home, I had a similar issue where the > shutdown/reboot is blocked by systemd-user-runtime-dir and I'm > certainly running in permissive mode on that machine. But on > other > machines it was not happening, I was planning to investigate > more, > but ENOTIME > > > Permissive mode shouldn't deny anything, just log what would be > denied by SELinux. So the bug could be either in the kernel or > in > libselinux (systemd shouldn't be aware that anything would be > denied). And indeed I see the following BUG in the provided > logs: > Aug 02 21:05:37 galahad kernel: BUG: kernel NULL pointer > dereference, address: 0000000000000060 > > Are you running the latest available kernel? > > >
I tested this on a manually compiled kernel 5.7.5 and 5.7.10 from kernel git, and on Debian's official 5.7.10 image in sid. They all run into the same oops. It is not specifically SELinux that's causing it, it looks like it's the auditing subsystem. If you look at the backtrace in the oops, you only see audit syscalls. I confirmed that by leaving SELinux on and turning off auditing, and it has the same behaviour: works without, oopses and hangs systemd-user-runtime-dir when turned on. So there's a call path somewhere when both SELinux and auditing are on that triggers this oops. Mart
