Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)

[Matthijs Kooijman]

severity 919259 normal
found 919259 232-25
retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN
thanks

Hey Michael,

> My suggestion would be to roll back to 232-25+deb9u1 and then gradually
> upgrading to deb9u2, deb9u2 ... deb9u3
Yeah, that was my intention. I discovered some interesting things.

 - On my host system, systemd is now also upgraded without problems.
 - Restarting a container works just fine, even with deb9u8. However,
   the problem occurs when re-execing (e.g. systemctl daemon-reexec).
 - Downgrading to deb9u1 and re-execing also breaks, so this is not
   broken by the upgrade that happened this week.
 - Looking in the logs, I found that the last time re-exec happened
   (succesfully) was on 2017-09-12. It seems that was from a manual
   upgrade, so I am not sure what version that was exactly. From old
   unattended upgrade e-mails, I *suspect* it was deb9u1.
 - Looking through my config git history, I did not find any seemingly
   relevant changes in the lxc config since 2017. However, I think I did
   upgrade from jessie to stretch since then (or maybe just before then,
   but I probably didn't restart the containers and/or system until
   later).
 - For good measure, I also tested the original 232-25 version, which
   also breaks.
 - When I remove `lxc.cap.drop = sys_admin` from the lxc config, reexec
   works fine again.

So it seems that *some* lxc upgrade since 2017 broke this. What is
broken is re-execing systemd inside a container running without
CAP_SYS_ADMIN.

I'm not sure if this means this bug should be against lxc instead, but
until we know more, I guess keeping it against systemd would be good.

Since booting still works (and this issue can be worked around be
rebooting the container), I'd say this issue can be downgraded
from important to normal. I've went ahead and did this, feel free to
revert if you feel otherwise.

Going forward, I guess it would be good to investigate why the re-exec
fails, based on the error messages shown:

  systemd[1]: Failed to create /../../init.scope control group: Operation not permitted
  systemd[1]: Failed to allocate manager object: Operation not permitted

One interesting question is also why the initial startup does *not* fail, but
the re-exec does.

I'm out of time again for now. I'll have a closer look at what this init.scope
control group is exactly and how systemd handles it on normal startup. Any
additional thoughts are welcome :-)

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190116/8b67a0e3/attachment.sig>