-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot start containers on Debian with apparmor enabled in the kernel. #1895
Comments
I can also reproduce this issue with 2.1.0-devel build from the sources |
And on Debian stable, booted with
|
This looks like the requested AppArmor profile has not been loaded into the kernel which means that AppArmor cannot do
|
yep, that looks like it
|
FWIW, on Stretch, I get the following with lxc and apparmor installed:
|
Can you try re-installing lxc after apparmor was installed? |
Same issue on Debian for me:
however apparmor blocks mounts:
and I get this in the lxc container log:
I did also re-install lxc after apparmor was installed. |
I have the same problem, any workaround? Without having to disable apparmor with kernel options, if possible |
lxc in debian testing and unstable at the moment disables apparmor for all containers by default while we don't have a fix for this. you want this;
|
This issue has been fixed in Debian by apparmor 2.11.1-4. See Debian bug 883703 for more information. I am thus dropping the workaround I had put into the Debian lxc packages. |
Dropping the workaround was a bad idea (imho). It ties lxc to a newer apparmor version not available in Stretch. Makes backporting lxc pretty difficult. Not to mention that lxc's control file doesn't set Conflicts: accordingly. I would suggest a line "Conflicts: libapparmor1 <= 2.11.1-4". I highly appreciate the lxc.aa_profile = unconfined |
a bad idea is not making use of a security feature like apparmor when it is available. your point about the dependency on libapparmor is valid, though, but "Conflicts:" is not the correct solution. I added an explicit dependency on the specific version of apparmor that has the fix we need. |
best thing would probably be, to have the patched version in Debian Strech and not the old, buggy one.. :) |
Issue is still persisting |
lxc/lxc#1895 apparmor guvenlik siklastirma kapsaminda yuklenen bir tool
@parithy I encountered a similar looking issue earlier today while trying to launch my first LXC container on Debian stable (using exclusively packages from the stable repositories). In the end, a simple edit: Later on I encountered a whole bunch of other issues, but with stopping containers. Their init process would become unkillable (even with kill -9 from the host), an issue which is easy to find on the internet but I could not find a consistent fix for. See e.g. |
debian 9 stretch on azure comes installed with libapparmor, but not apparmor itself so i couldn't start the container. i had to use the workaround given by terceiro |
to get an Alpine Linux lxc container from the |
Required information
lxc-start --version
: 2.0.9lxc-checkconfig
: lxc-checkconfig.txtuname -a
: Linux $HOST 4.13.0-1-amd64 Prefix tests with lxc-test- #1 SMP Debian 4.13.10-1 (2017-10-30) x86_64 GNU/Linuxcat /proc/self/cgroup
: cgroup.txtcat /proc/1/mounts
: mounts.txtIssue description
After apparmor was enabled in the Debian kernel, I cannot start containers anymore. Log:
Adding
lxc.aa_allow_incomplete = 1
to the config, as the error message says, does not help, but produce a different error:Original Debian bug report: #880502
The text was updated successfully, but these errors were encountered: