You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
VM instances: passt cannot run on Ubuntu 24.04 Docker hosts (guests fall back to user-mode networking) #90
VM instances (#82) give the guest the VM container's own address through passt. On Ubuntu 24.04 Docker hosts passt cannot run, so guests fall back to QEMU user-mode networking: NAT at 10.0.2.15, no private address of their own, only the ports the security groups allowed at launch are forwarded, and a security group change rebuilds (reboots) the guest.
What the GitHub ubuntu-latest runner showed (CI of #82):
With passt at /usr/bin/passt inside the container, the host's AppArmor profile for passt (from the host's passt package, probably installed alongside podman) attaches to it by path even though the container runs apparmor=unconfined. Evidence: Unable to open /proc/sys/net/ipv4/ip_local_port_range: Permission denied as root. That passt started and the guest got DHCP, but passt died around the first inbound TCP connection (the published SSH port).
EC2: VM-backed instances (stage 1) #82 now runs passt from /usr/local/libexec/homecloud/passt, outside that profile. Unconfined, it then hits Ubuntu's restriction on unprivileged user namespaces (kernel.apparmor_restrict_unprivileged_userns=1, the 24.04 default): Failed to detach isolating namespaces: Operation not permitted / Failed to sandbox process, exiting. The entrypoint now catches this before the guest boots and falls back to user-mode networking with a hint.
Ways to get passt back on such hosts, to evaluate:
Ship an AppArmor profile for the VM container's passt (allowing userns, mount, umount, pivot_root and what passt needs) that homecloud server install loads on hosts with AppArmor, and set HC_VM_APPARMOR to it (the option exists; nothing loads a profile yet).
Document sysctl kernel.apparmor_restrict_unprivileged_userns=0 as the alternative (host-wide, weaker).
Check whether a newer passt can run with a reduced sandbox when user namespaces are restricted.
Find out what killed the profile-confined passt at the first inbound connection (case 1), in case other hosts hit it.
CI exercises the fallback today (vm_network=user is logged as a NOTE by the VM tests).
VM instances (#82) give the guest the VM container's own address through passt. On Ubuntu 24.04 Docker hosts passt cannot run, so guests fall back to QEMU user-mode networking: NAT at 10.0.2.15, no private address of their own, only the ports the security groups allowed at launch are forwarded, and a security group change rebuilds (reboots) the guest.
What the GitHub
ubuntu-latestrunner showed (CI of #82):/usr/bin/passtinside the container, the host's AppArmor profile for passt (from the host's passt package, probably installed alongside podman) attaches to it by path even though the container runsapparmor=unconfined. Evidence:Unable to open /proc/sys/net/ipv4/ip_local_port_range: Permission deniedas root. That passt started and the guest got DHCP, but passt died around the first inbound TCP connection (the published SSH port)./usr/local/libexec/homecloud/passt, outside that profile. Unconfined, it then hits Ubuntu's restriction on unprivileged user namespaces (kernel.apparmor_restrict_unprivileged_userns=1, the 24.04 default):Failed to detach isolating namespaces: Operation not permitted/Failed to sandbox process, exiting. The entrypoint now catches this before the guest boots and falls back to user-mode networking with a hint.Ways to get passt back on such hosts, to evaluate:
userns,mount,umount,pivot_rootand what passt needs) thathomecloud server installloads on hosts with AppArmor, and setHC_VM_APPARMORto it (the option exists; nothing loads a profile yet).sysctl kernel.apparmor_restrict_unprivileged_userns=0as the alternative (host-wide, weaker).CI exercises the fallback today (
vm_network=useris logged as a NOTE by the VM tests).