dhcp apparmor profile complains about lxd client

Status changed to 'Confirmed' because the bug affects multiple users.

Which are the perceivable consequences of this bug?

When answered please set status back to "confirmed". Thank you.

Removing the LXD task, this is yet another apparmor bug from the apparmor stacking/namespacing change which was backported to Xenial.

Basically, dhclient is now being confined by apparmor inside the container, unfortunately, apparmor doesn't behave in the exact same way when it's interpreting a profile as part of a stack vs as the single profile in the stack (on the host).

We've seen a number of file_perm and related issue show up, typically related to permissions to access the failing binary itself. Though in this case, the path does seem a bit weirder?

Anyway, not a LXD bug but an apparmor one. I'm sure John will have an idea of what's going on here :)

> Removing the LXD task, this is yet another apparmor bug from the apparmor stacking/namespacing change which was backported to Xenial.

Well, that explains a lot. 16.04 was formerly stable but recently began to drive me crazy because of so many apparmor problems with almost every major daemon or browser, and an aa-notify which just vomates hundreds of messages onto the desktop faster than one can click them away.

I am not an apparmor expert, but was able to deal with it for years, but suddenly have the problem that adding permissions to the local-files for local extensions does not solve problems as expected.

I think it is not overestimated to say that this apparmor thing broke the usability of 16.04.

What in the world was the reason to backport these problems into a stable release?

> Which are the perceivable consequences of this bug?

I currently cannot survey the consequences, since I am not familiar with the recent semantic changes of apparmor (are there any docs? Any hints to the users about changes? Any release notes?)

For some time now I am spending and wasting lots of time to hunt bugs in all sorts of software like firefox, chromium, ejabberd, lxd,... which is all caused by sudden apparmor trouble.

A side effect of all these bugs is that log files (and desktops through aa-notify) are flooded with hundres, thousands, millions of log messages, which jams a system and makes it impossible to find really important log messages, and, btw., can ruin flash memory in SSDs and SD-Cards within short time.

Why on earth has one backported this pile of bugs into a LTS version?

This rendered Ubuntu so unreliable, that I have to consider to change to CentOS or something like this for servers in order to get SELinux instead.

Is there any way to get 16.04 stable again?

BTW: How should I answer the question about the consequences of the bug, if I don't see any docs about was has changed with apparmor?

Hadmut, AppArmor's stacking support was intended to allow supporting unmodified Ubuntu inside LXD containers. If you're feeling up for some experimentation, you could try to disable this feature by setting the kernel.unprivileged_userns_apparmor_policy sysctl to 0 early in a system boot, preferably before LXD starts. This should cause the attempts to set policy within LXDs to fail, and either the services will then refuse to start or they'll fall back to their old behaviour. (This reflects my lack of familiarity with LXD.)

I'll note that this is a wild guess; I'd feel more comfortable giving this advice on IRC than in a public bug tracker where it might do more harm than good. But I'm cautiously optimistic that this might give you a system you'd be happier using.

Thanks