[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