[systemd-devel] bpfilter blocks root unmount during shutdown

[Andrei Borzenkov]

24.09.2018 19:52, Lennart Poettering пишет:
> On Mo, 24.09.18 19:30, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> 
>> 24.09.2018 16:20, Lennart Poettering пишет:
>>> On So, 23.09.18 10:38, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
>>>
>>>> Dracut /shutdown script first tries to kill all processes still running
>>>> off old root. Unfortunately this fails for special user process that
>>>> runs bpfilter because it does not include reference to /oldroot in
>>>> places where dracut looks for in kilall_proc_mountpoint()
>>>
>>> Hmm, when we invoke the /shutdown executable we already executed our
>>> process killing spree as part of systemd-shutdown. How come your
>>> processes even survive that long?
>>
>>
>>         p = procfs_file_alloca(pid, "cmdline");
>>         f = fopen(p, "re");
>>         if (!f)
>>                 return true; /* not really, but has the desired effect */
>>
>>         count = fread(&c, 1, 1, f);
>>
>>         /* Kernel threads have an empty cmdline */
>>         if (count <= 0)
>>                 return true;
>>
>>
>> This process is spawned as special kernel thread, even though it is
>> otherwise normal user process.
> 
> 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.

> If so, yuck...
> 
> Under which parent PID do they show up? kthreadd or somewhere further
> down?
> 

I showed it in original post.

10:~ # ps -ef | fgrep '[none]'
root       984     2  0 09:46 ?        00:00:00 [none]

Yes, this is kthreadd.

> 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.