[pkg-lxc-devel] Bug#925899: Bug#925899: lxc: Unprivileged containers fail to start after recent updates
Evgeni Golov
evgeni at debian.org
Sun Mar 31 15:21:34 BST 2019
Unprivileged containers is the only thing I use in Stretch atm, so call me biased. But it's also the thing that does not work out of the box (you need a sysctl, you need to add the user to lxc-net config and you need to adjust the users lxc.conf for the uid map). As such, I'd say having to set another config var is not a big deal as long it's properly documented and announced in NEWS.Debian.
My 0.02€
On 31 March 2019 16:11:53 CEST, "Pierre-Elliott Bécue" <peb at debian.org> wrote:
>Le dimanche 31 mars 2019 à 14:55:52+0200, intrigeri a écrit :
>> Pierre-Elliott Bécue:
>> > Cc-ing intrigeri: I'm reconsidering the /etc/lxc/default.conf
>setting
>> > regarding apparmor.profile. Putting generated breaks many unpriv
>> > containers as they have no apparmor.profile set in their
>configuration.
>>
>> Considering kernel.unprivileged_userns_clone is disabled by default
>> on Debian, IMO we should:
>>
>> - Optimize for the Debian defaults, i.e. privileged containers:
>> - Keep the settings we added recently in /etc/lxc/default.conf
>> - Replace "Suggests: apparmor" with "Depends: apparmor", because
>> the default config will create containers that fail to start
>> if the apparmor package is not installed.
>>
>> - Document how to use unprivileged containers on Debian. It's not as
>> if they were previously working fine by default and AppArmor broke
>> them — regardless of AppArmor, on current sid with the default
>> kernel settings and lxc.apparmor.profile = unconfined, trying to
>> start an unprivileged container fails in a very much user
>> unfriendly way:
>>
>> conf.c: chown_mapped_root: 3250 lxc-usernsexec failed:
>Permission denied - Failed to open tt
>>
>> That's a first usability stumbling block. The new
>> lxc.apparmor.profile default setting merely adds a second one.
>>
>> So I think README.Debian should document the need for
>> kernel.unprivileged_userns_clone=1 and for
>> lxc.apparmor.profile = unconfined
>
>Yes and no, the issue is that we introduced a new problem which made
>the
>unpriviledged containers of user having already set the kernel properly
>not working either.
>
>There is a tradeoff in your current solution, and I wonder if it is the
>appropriate one.
>
>I'm Cc-ing Antonio and Evgeni to get their POV.
>
>> - Take care of the Stretch→Buster upgrade path for unprivileged
>> containers, by mentioning in NEWS.Debian that previously working
>> unprivileged containers now need lxc.apparmor.profile =
>unconfined.
>
>The apparmor.profile = lxc-container-default-cgns works too, but will
>prevent systemd isolation features to work.
>
>--
>Pierre-Elliott Bécue
>GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
>It's far easier to fight for one's principles than to live up to them.
>
>_______________________________________________
>Pkg-lxc-devel mailing list
>Pkg-lxc-devel at alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-lxc-devel
More information about the Pkg-lxc-devel
mailing list