Control: reassign -1 lxc On Wed, 16 Jan 2019 09:52:47 +0100 Matthijs Kooijman <matth...@stdin.nl> wrote: > 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 :-)
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. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers