From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Rxfi9mKw; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 04B125A061A for ; Wed, 29 Jan 2025 19:49:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738176540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sXhc8nlkScaWz4rNN5vKsQt0IMSVHW67uatMvFui6jY=; b=Rxfi9mKw2y5pQzt8HJeeJYBppy8jPsUY0Gx4ChjeEdt4f20USNL0PglP8y9r+cPomYdvU3 DY1bHY9T0DeDhyuB5FrcGcBipsLVw0B6qiuQV2KJtSF0Wh/qtkDgcppppWlt5xT5LVPiJ+ IQKhoBcKnBu5aUMKm9+lWsnisH3CQpc= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-564-rj_XaAtlPDeFWBzbiLRXBA-1; Wed, 29 Jan 2025 13:48:59 -0500 X-MC-Unique: rj_XaAtlPDeFWBzbiLRXBA-1 X-Mimecast-MFC-AGG-ID: rj_XaAtlPDeFWBzbiLRXBA Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-436225d4389so5054815e9.1 for ; Wed, 29 Jan 2025 10:48:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738176536; x=1738781336; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=sXhc8nlkScaWz4rNN5vKsQt0IMSVHW67uatMvFui6jY=; b=Ipz9SikTC8fdIjWTwLakY4WUXeXXVZ8D1fvc4fRvJ45fLVB6xkyy1JcN4gKV4ISGm+ K+DKr9jnLAxUQ1Y+Ot6rN/tyB5apyN8luPekXfOEo0OQ7q7tEQurLbjijAf1n38sI70o 9rZsLL/sdgjXVfkI1ilIxQxCKjZMS0tBnWtC0VDMfdVUoR6T7ZZvfml6+FO8sEA+7Fkq qXKDHdsi7XVPQVqhGSrzvBh7vHFrZXNgGtDVTe/B7IqwFraCtYKekJ+B2mcxEJd4hK6d x7TRooq/4UOMwHmqMyh2MCLUK1RmO4riqF0Ya4Kwhqgl2IguRPZTLBLOzQw4sqGhd9vR Vyzg== X-Gm-Message-State: AOJu0Yzr/QC5jLQ44B3x/qPFOmEm6qq+AjxKl+rhLvR8C7em+0bHc0GX wTkI4kZzIow+wV3mX/uCk/a44ntOK4J6vqb7/tSkQRhjFngWSPJ0l0soYNm8W3+occpoqgYzpe3 bPNgEVWUOLZl2xM2sZTb1imwObUMP2ysU8UAB6UkBt7UTaHCERCRqJLWA41YVR/dVzssPIrOC6w p4VwBni6FMrc05sVsGqgePw2hu2SR8IigW X-Gm-Gg: ASbGnct1QfjZ2QbVUf/vSYQzvtMKWWIVwD444eFdRfwtDreYlhevDx+7RLWjXZ6yj+E 1t9vLVmMrpqZlkO/4Y50dd3DtfzZFa4nVTw/F92NZoRT/fHhxZ2I+7+Ey3Ifu7/+SI2Fex/yJIx 3AfmToohTHeIQdZq0/nYb50w1kFBL02tUdxYIv3ZGsjZ1YmwTYRrMI5fVyFFzOvamimBXGfHEGk NFi2LS7FeC6dHu8H67PZpTVwvX+kMjYIMMqfKuh0O739ukdUVJfHE4djDqBS2+dl9+Gyq/UqS4B BBxicNulTCw+dgG1 X-Received: by 2002:a05:600c:83c6:b0:434:f2af:6e74 with SMTP id 5b1f17b1804b1-438e170e7b5mr3723895e9.15.1738176536579; Wed, 29 Jan 2025 10:48:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHY6hDIkkD6rtb2Bh9DJ3kbEtengfE2Ai01KaHJI7np+uERRxamWBy1+zbgotu1WnNDJ1vgkA== X-Received: by 2002:a05:600c:83c6:b0:434:f2af:6e74 with SMTP id 5b1f17b1804b1-438e170e7b5mr3723735e9.15.1738176536148; Wed, 29 Jan 2025 10:48:56 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438dcc2ef08sm32244595e9.22.2025.01.29.10.48.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2025 10:48:55 -0800 (PST) Date: Wed, 29 Jan 2025 19:48:54 +0100 From: Stefano Brivio To: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: <20250129194854.6b67fbfe@elisabeth> In-Reply-To: References: <20250129104112.0756df5c@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: O0qFKWPFkS4a8iWI_C5WsL7gDUSfuhWpPRYjgT5yZj4_1738176538 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: OLLTQBTJ6SFYAENVSZBYOMXKEKDXA52K X-Message-ID-Hash: OLLTQBTJ6SFYAENVSZBYOMXKEKDXA52K X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "passt-dev@passt.top" , Andrea Bolognani X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 29 Jan 2025 18:10:36 +0000 Prafulla Giri wrote: > Hello, > > On Wednesday, January 29th, 2025 at 3:26 PM, Stefano Brivio wrote: > > > Hi, > > > > On Wed, 29 Jan 2025 09:14:12 +0000 > > Prafulla Giri prafulla.giri@protonmail.com wrote: > > > > > Esteemed maintainer, > > > > > > First and foremost, thank you very much for your hard work: passt is awesome and allows one to run more useful user-space VM-s. > > > > > > I have encountered 2 particular issues with the usage of passt with Debian, and wanted to bring them to your attention as I think you are probably the best person to deal with this. I do plan on sending a report to the Debian team afterwards. > > > > > > For reference, I tested these on Debian Testing Daily Image dated 28 January 2025, with updates, and the version of passt available with it is passt 0.0~git20250121.4f2c8e7-1 > > > > > > - Passt's default Apparmor config needs to allow writes to $XDG_RUNTIME_DIR (which is at /run/user/$UID). Currently it doesn't. Virt-manager, at least, tries to create the necessary sockets in the directory but apparmor prevents that from happening (and the error message Virt-Manager gives isn't helpful either: the first time around I falsely believed it was a segfault or similar issue). I managed to get passt working past this flaw (pun intended) by manually disabling apparmor for the binary. Passt works just fine in Fedora 41 as it doesn't use Apparmor but uses SELinux, and thus the configs don't affect it. > > > > > > Thanks for reporting this! I'm the maintainer of the Debian package, by > > the way. Cc'ing Andrea, who is a maintainer of the libvirt package for > > Debian and surely more knowledgeable about this. > > I'm glad to have bumped into you. Because of the email domain, I thought you weren't the Debian maintainer. Silly me. :) > > Note that virt-manager uses passt through libvirt (I think that's only > > possibility) and this should actually be allowed in libvirt's AppArmor > > policy, in the sub-profile for passt: > > > > https://gitlab.com/libvirt/libvirt/-/blob/0264a7704ada52f686cafe8f6402d5b60f9f0fc4/src/security/apparmor/libvirt-qemu.in#L204 > > > > the rationale is that passt itself doesn't know which directory libvirt > > will pick for its socket and PID files, so libvirt's policy has to > > specify that. > > > > So I think you should file an issue for the libvirt package in this > > case, unless Andrea has some pointers. > > I will wait for the maintainers input on this one. One thing that might help meanwhile is if you have a look at /var/log/audit/audit.log after the failure occurs. Look for 'passt' there. There should be a message logging a denied access to some file: what does it say? > > > - This second issue is perhaps a bit more Debian-specific, but I am going to mention it so that you might drop some hints for the Debian maintainers to debug this: Once Apparmor is disabled and a VM is configured to work with passt, DNS resolution doesn't work in the VM (IP Addresses work just fine) i.e. ping fsf.org doesn't work but `ping 209.51.188.174` does. The hypervisor details follow: > > > $ virsh version # on Debian Testing a.k.a. 'Trixie' > > > Compiled against library: libvirt 11.0.0 > > > Using library: libvirt 11.0.0 > > > Using API: QEMU 11.0.0Running hypervisor: QEMU 9.2.0 > > > This, again, isn't an issue with Fedora 41, where everything just works. The hypervisor details for Fedora 41 are: > > > $ virsh version # on Fedora 41 > > > Compiled against library: libvirt 10.6.0 > > > Using library: libvirt 10.6.0 > > > Using API: QEMU 10.6.0 > > > Running hypervisor: QEMU 9.1.2 > > > > > > Oops. Can you share the command line of passt as run by libvirt > > (say, 'ps aux|grep passt') for this case? passt has some basic > > DNS forwarding capabilities, which are configured depending on > > the host's resolver configuration. > > > > Certainly! I'm sorry I didn't do this earlier. I'd checked on this: there is no difference between the command that runs passt on Fedora 41 or Debian Trixie. > > This is the command on Fedora 41: > passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0-passt.pid > > and this is the command on Debian Trixie: > passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0-passt.pid Okay, nothing unexpected so far. Could you also please compare the output of 'passt -f -d' between the two cases? Just terminate it with ^C once you have the output. How are resolvers configured on the two hosts? What does /etc/resolv.conf say? If nothing is visible from there, next check: 'virsh edit vm1' on Debian and add a log file in the XML, that is, replace this line: with: and then share the log. -- Stefano