[pkg-lxc-devel] Bug#919259: systemd: (Security?) update breaks systemd (inside unprivileged container?)

[Michael Biebl]

Control: reassign -1 lxc

On Wed, 16 Jan 2019 09:52:47 +0100 Matthijs Kooijman <matthijs at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20190228/7cf585d6/attachment.sig>