Bug 1324188

Summary: RFE: allow sharing libvirt/qemu.conf between system and session daemon
Product: [Community] Virtualization Tools Reporter: Marcelo Ricardo Leitner <mleitner>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: agedosier, berrange, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-08-18 13:58:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Marcelo Ricardo Leitner 2016-04-05 18:47:12 UTC 
Description of problem:
If I run virt-manager, I can list and manage my guests.
If I run virsh, I also can do it, but only if I specify '-c qemu:///system'
But that should be the default already, according to:

$ sudo tail /etc/libvirt/libvirt.conf
#uri_aliases = [
#  "hail=qemu+ssh://root.example.com/system",
#  "sleet=qemu+ssh://root.example.com/system",
#]

#
# This can be used to prevent probing of the hypervisor
# driver when no URI is supplied by the application.

uri_default = "qemu:///system"
----

@localhost ~]$ LANG=C virsh list --all 
 Id    Name                           State
----------------------------------------------------

@localhost ~]$ LANG=C virsh -c qemu:///system list --all 
 Id    Name                           State
----------------------------------------------------
 4     centos7-1                      running
 -     centos7-2                      shut off
 -     rhel5.8                        shut off

Copying /etc/libvirt/libvirt.conf to ~/.config/libvirt/libvirt.conf, the file is read by virsh and it uses the default value (confirmed using strace).

I noticed this:
drwx------. 5 root root 4096 Abr  5 15:27 /etc/libvirt/
but just allowing access to it is not enough, something else seems to be missing. On strace I don't even see it trying to access this dir/file, only the one under $HOME.

Version-Release number of selected component (if applicable):
libvirt-client-1.2.18.2-2.fc23.x86_64
libvirt-daemon-1.2.18.2-2.fc23.x86_64

How reproducible:
Always

Steps to Reproduce:
As above

Actual results:
Missing default values from config file

Expected results:
NOT missing default values from config file

Additional info:
I'm using this:
/etc/polkit-1/localauthority/50-local.d/mrl-libvirt.pkla
[mrl libvirt access]
Identity=unix-user:mrl
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

for password-less use.
Comment 1 Daniel Berrangé 2016-04-06 08:59:27 UTC 
That config file is used as root. If you are a non-root user you should be using $HOME/.config/libvirt/libvirt.conf
Comment 2 Marcelo Ricardo Leitner 2016-04-06 12:02:17 UTC 
Why is that so? It doesn't really follow the standards, specially because then there is no way to have system-wide defaults for all users.
Comment 3 Daniel Berrangé 2016-04-06 12:20:24 UTC 
The /etc/libvirt directory is not even readable by unprivileged users as it contains files with security sensitive information, so there's no possibility of reading the config file from there as a non-root user.
Comment 4 Marcelo Ricardo Leitner 2016-04-06 12:32:31 UTC 
That's one of the points on the report. The files that may have security sensitive information could be restricted but the directory itself doesn't need to be, as, unlike its subfolders, no random new files seems to be expected in there. And it doesn't exclude the possibility to move the file to outside of it, of course.

But come on, that's an implementation detail. Let's focus on the concepts first, shall we? Why do root have a different default than other users? Not using the same default is not adding any extra security to it. Why libvirt doesn't want to allow a global default file for all users?
Comment 5 Cole Robinson 2016-04-11 23:00:32 UTC 
We could possibly enable read permissions on libvirtd.conf, but we can't on qemu.conf, since it can contain security sensitive info like a default vnc/spice password. Enabling access for one file and not the other would be problematic, so it's not a simple fix.

That said I agree that it would be nice to have a way to share config across system and session daemons, but it will take some work or a new directory to enable it. Moving to the upstream tracker
Comment 6 Marcelo Ricardo Leitner 2016-04-12 00:04:40 UTC 
Update path can be complicated, but filesystem-wise it should be possible to have qemu.conf with perms 0600. Like iscsi stuff:

$ ls -la /etc/iscsi/
total 32
drwxr-xr-x.   2 root root  4096 Nov 16 11:10 .
drwxr-xr-x. 164 root root 12288 Abr 11 07:58 ..
-rw-r--r--.   1 root root    49 Mai 21  2015 initiatorname.iscsi
-rw-------.   1 root root 11853 Nov  3 23:11 iscsid.conf
$ cat /etc/iscsi/iscsid.conf 
cat: /etc/iscsi/iscsid.conf: Permission denied

Thanks for moving this forward.
Comment 7 Daniel Berrangé 2021-08-18 13:58:55 UTC 
Closing this since the daemons are intentionally using separate configurations and mixing them does not make sense.