hostnamectl fails under lxd unpriv container
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Confirmed
|
Critical
|
Unassigned |
Bug Description
1. % lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04
2. % apt-cache policy apparmor
apparmor:
Installed: 2.10.95-0ubuntu2
Candidate: 2.10.95-0ubuntu2
Version table:
*** 2.10.95-0ubuntu2 500
500 http://
100 /var/lib/
% apt-cache policy lxd
lxd:
Installed: 2.0.0-0ubuntu4
Candidate: 2.0.0-0ubuntu4
Version table:
*** 2.0.0-0ubuntu4 500
500 http://
100 /var/lib/
3. lxc launch ubuntu-daily:xenial x1
lxc exec x1 /bin/bash
root@x1:~# hostnamectl status
Static hostname: x1
Icon name: computer-container
Chassis: container
Machine ID: 833b8548c7ce411
Boot ID: 9d5fbb053cf7494
Virtualization: lxc
Operating System: Ubuntu 16.04 LTS
Kernel: Linux 4.4.0-18-generic
Architecture: x86-64
4. hostnamectl status hangs indefinitely
On the host, there are some audit messages for each invocation of hostnamectl
[411617.032274] audit: type=1400 audit(146169556
It's related to socket activation. One can workaround this by running systemd-hostnamed in the background first
root@x1:~# /lib/systemd/
[1] 2462
root@x1:~# hostnamectl status
Static hostname: x1
Icon name: computer-container
Chassis: container
Machine ID: 833b8548c7ce411
Boot ID: 9d5fbb053cf7494
Virtualization: lxc
Operating System: Ubuntu 16.04 LTS
Kernel: Linux 4.4.0-18-generic
Architecture: x86-64
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apparmor 2.10.95-0ubuntu2
ProcVersionSign
Uname: Linux 4.4.0-18-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME-Flashback
Date: Wed Apr 27 11:19:27 2016
InstallationDate: Installed on 2016-01-01 (117 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151209)
ProcKernelCmdline: BOOT_IMAGE=
SourcePackage: apparmor
Syslog:
UpgradeStatus: No upgrade log present (probably fresh install)
tags: | added: rls-bb-incoming |
Changed in apparmor (Ubuntu): | |
status: | Fix Committed → Confirmed |
Thanks for the bug report. The problem is now understood. systemd is calling lockf() on an anonymous socket file and the AppArmor profile language does not support a way to grant file locking permissions on a socket that does not have a path associated with it.
The AppArmor socket file rule type needs to gain a new permission for file locking. This will require changes to the kernel and apparmor_parser and, eventually, the AppArmor Python utilities.