[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access

Let's see what changed around that time:

  https://launchpad.net/ubuntu/+source/dbus/1.6.12-0ubuntu8
  https://launchpad.net/ubuntu/+source/dbus/1.6.12-0ubuntu9
  https://launchpad.net/ubuntu/+source/apparmor/2.8.0-0ubuntu30
  https://launchpad.net/ubuntu/+source/isc-dhcp/4.2.4-7ubuntu8
  https://launchpad.net/ubuntu/+source/linux/3.11.0-12.18
  https://launchpad.net/ubuntu/+source/linux/3.11.0-12.19 (looks irrelevant, though)

Reproducer:
- Start a minimal saucy VM (run-adt-test -sUl -r saucy), or boot a live system in KVM, etc.
- Install dependencies: sudo apt-get install --no-install-recommends python3 gir1.2-networkmanager-1.0 network-manager hostapd iw python3-dbusmock
- Get the tests: apt-get source network-manager; cd network-manager-*
- Run a single test: sudo debian/tests/nm ColdplugEthernet.test_auto_ip4

This will fail with log output, and reproduce above error.

This also reproduces on a current trusty installation, with the same reproducer (except for the "start VM" part, of course). This will kick you off your "real" network though.

If I install and boot https://launchpad.net/ubuntu/+source/linux/3.11.0-11.17 on a current trusty system this bug goes away. So https://launchpad.net/ubuntu/+source/linux/3.11.0-12.18 was the one that caused the regression.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1244157

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

More kernel logs aren't relevant here, and I already stated the exact kernel version which introduced this regression.

From discussion with Jamie: Changing /etc/apparmor.d/sbin.dhclient to

   /usr/lib/NetworkManager/nm-dhcp-client.action flags=(attach_disconnected) {

does the trick. Apparently this happens because the NM tests unshare the file system namespace.

They do this because they mount tmpfses over /run/NetworkManager, /etc/NetworkManager and similar, so that they don't destroy the real files on the production system.

Is there any way to temporarily add this attach_disconnected flag without having to touch files in /etc? I wouldn't want to actually sed -i there as these tests are supposed to be running on a desktop installation too (that's why I go through all the fuss in the first place).

For adding the attach_disconnected flag, unfortunately there isn't a convenient way to apply attach_disconnected without modifying the profile directly.

So yes this is because of the unshare of the file system namespace. Currently the only work around is the use of the attach_disconnected flag. Alternate solutions are coming as part of the work to support lxc

Martin:
The only way to temporarily add the attach_disconnected flag is to manually replace the profile with a version that has the flag added. The manually loaded profile can be from anywhere
  apparmor_parser -Kr <profile file>

@John: Thanks a lot for the tip with "apparmor_parser -Kr <profile file>", that works perfectly!

I'll add that to the NM tests. If this is supposed to work that way, please feel free to close the AppArmor task. If it's just a workaround and D-BUS access is supposed to continue to work from an unshared file system, it can be kept open.

This bug was fixed in the package network-manager - 0.9.8.4-0ubuntu3

---------------
network-manager (0.9.8.4-0ubuntu3) trusty; urgency=low

  * Set "allow-stderr" for debian/tests/apparmor_workaround to avoid failure
    on AppArmor warnings.
 -- Martin Pitt <email address hidden> Tue, 05 Nov 2013 09:48:28 +0100

I meet this problem on saucy too. So will the patch be backported to saucy soon? Thanks.

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

Martin Pitt, could you please provide the linux commit that this regressed in as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244157/comments/4 via https://wiki.ubuntu.com/Kernel/KernelBisection ?

Christopher, that's probably something that the AppArmor devs (John/Tylor) should look into. When I discussed this with John and Tylor, they already seemed to know which area of AppArmor hits this.