Re: bpfilter blocks root unmount during shutdown

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 24.09.18 20:17, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote:

> > I am sorry, what? Are you saying there's now a third kind of task?
> > real kernel threads, real userspace processes, and weird shit running
> > kernel code that in turn runs userspace supplied programs, and all
> > that under user control?
> > 
> 
> No, it is not exactly "user control". It runs executable embedded into
> kernel module. So it is not arbitrary code. In this particular case at
> least.

By "user control" I meant that they are kill()-able by users (kernel
threads generally are not).

> > Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they
> > pass the recently reworked is_kernel_thread() tests?
> 
> No. The flags are 4194560 == 0x400100 == PF_RANDOMIZE|PF_SUPERPRIV.
> 
> And sorry, I cannot comment on "these processes"; I have seen only one
> concrete example. I have no idea how widespread use of this facility is.
> 
> > We might want to update killall.c then so that it does not make
> > assumptions on /proc/$PID/cmdline validity anymore, but strictly uses
> > is_kernel_thread(). That should fix things properly for you, no? That
> > way dracut won't even see these new kind processes at all...
> 
> Well, I suppose there could be corner cases when executable and
> libraries are from different filesystems, but this better waits for real
> life example then.

I prepped this PR:

https://github.com/systemd/systemd/pull/10159

I think this should fix your issue, could you test? (using PF_KTHREAD
checking is more correct anyway, hence regardless this should really
be the right way and be merged)

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel