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
signature.asc
Description: PGP signature