Le 3/08/20 à 12:46, Laurent Bigonville a écrit :
On Sun, 2 Aug 2020 22:08:56 +0200 Mart van de Wege <m...@vdwege.eu> wrote:
> On Sun, 2 Aug 2020 21:59:05 +0200
> Michael Biebl <bi...@debian.org> wrote:
>
> > Am 02.08.20 um 21:41 schrieb Mart van de Wege:
> > > Package: systemd
> > > Version: 245.7-1
> > > Severity: normal
> > >
> > > With SELinux enabled (booting with selinux=1 security=selinux), as
> > > soon as systemd wants to clean up /run/user/<UID> for a session,
> > > the kernel will oops, leaving the systemd-user-runtime-dir process
> > > that's trying to clean up the directory in an uninterruptible sleep
> > > (D) state.
> >
> > I fail to see how this is a systemd bug. This looks more like a kernel
> > and/or Selinux issue to me.
> >
> You have a point there. I selected systemd because it at first appeared
> to be a systemd bug (process hangs), but of course, if it causes an
> oops reliably with selinux enabled (which it does), it should be
> retargeted to those packages.
>
> Is that still possible, or should we close this one and let me refile?
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)?
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?
Actually I can reproduce this with 5.7.10 (which is the latest available
kernel in debian). I would reassign to the kernel, but this looks more
like a problem with the audit framework than a problem with SELinux
itself if I can trust the trace in dmesg
