[pkg-lxc-devel] Bug#925899: lxc: Unprivileged containers fail to start after recent updates

[intrigeri]

Hi,

Regis Smith:
>> > lxc-start: test: lsm/apparmor.c: apparmor_prepare: 974 Cannot use
> generated profile: apparmor_parser not available

I've reproduced this problem and I could fix it with:

  lxc.apparmor.profile = unconfined

Regis, can you please confirm this fix works for you as well?

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

 - 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.

Thoughts?

Cheers,
-- 
intrigeri