Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)
biebl at debian.org
Thu Feb 28 19:06:16 GMT 2019
Control: reassign -1 lxc
On Wed, 16 Jan 2019 09:52:47 +0100 Matthijs Kooijman <matthijs at stdin.nl>
> severity 919259 normal
> found 919259 232-25
> retitle 919259 Reexecuting fails in containers without CAP_SYS_ADMIN
> 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
> - 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
> 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: Failed to create /../../init.scope control group: Operation not permitted
> systemd: 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 :-)
I'm going to re-assign this to lxc, simply because they know more about
lxc then myself. I have no idea how well supported unprivileged
containers are in stretch. Maybe this is just a configuration issue.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Pkg-systemd-maintainers