Bug 2033491 - [Machines] vm created by command with non-root user can not be listed on Virtual Machines page [NEEDINFO]
Summary: [Machines] vm created by command with non-root user can not be listed on Virt...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: util-linux
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: Radka Brychtova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-17 02:05 UTC by Xianghua Chen
Modified: 2023-07-03 07:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-03 07:56:07 UTC
Type: Bug
Target Upstream Version:
Embargoed:
xchen: needinfo? (skobyda)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-106055 0 None None None 2021-12-17 02:06:34 UTC

Description Xianghua Chen 2021-12-17 02:05:19 UTC
Description of problem:
[Machines] vm created by command with non-root user can not be listed on Virtual Machines page 

Version-Release number of selected components (if applicable):
cockpit-machines-256-1.el9.noarch
cockpit-258-1.el9.x86_64
libvirt-dbus-1.4.1-5.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a non root user in wheel group by follow command

# useradd -G wheel admin
# passwd admin

2. Create the default pool directory for the new created user, then copy a image to this directory(use cirros.qcow2 in this case), make sure the owner of the dir&image is the new added user: admin

# mkdir -p /home/admin/.local/share/libvirt/images
# cp /var/lib/libvirt/images/cirros.qcow2 /home/admin/.local/share/libvirt/images/subVmTest1-2.img 
# chown admin -R /home/admin/.local/share/libvirt/images

3. Login cockpit with the new created user, then switch to machines page.
After that, switch to admin, create a session VM with the image copied in step 2(user command below)  :
# su - admin
# virt-install --connect qemu:///session --name subVmTest1 --os-variant cirros0.4.0 --boot hd,network --vcpus 1 --memory 128 --import --disk /home/admin/.local/share/libvirt/images/subVmTest1-2.img --graphics vnc,listen=127.0.0.1 --console pty,target_type=serial --console pty,target_type=virtio --noautoconsole

4. The new created vm is not shown on the vm page. Refresh the vm page, the new created vm still can not be listed.
But it can be listed by command: 
# virsh list --all
 Id   Name         State
----------------------------
 2    subVmTest1   running

Actual results:
As shown in step 4.


Expected results:
The vm should be listed on the cockpit-machines page after step 4.

Additional info:
Same problem on RHEL8&RHEL9.

Comment 1 Xianghua Chen 2022-06-20 12:10:06 UTC
It's ok on RHEL8.7 per yunyang's comments, with 
cockpit-machines-270-1.el8.noarch + RHEL-8.7.0-20220605.0 BaseOS x86_64

Only exist on RHEL9.1 now: 
cockpit-machines-269-1.el9.noarch + RHEL-9.1.0-20220608.0

Comment 2 Katerina Koukiou 2022-11-22 11:33:23 UTC
The bug is that running `su - username` does not start a proper Linux session, pam_systemd, and such -- and thus no $XDG_RUNTIME_DIR

IN specific to this bug, the virtqemud socket that gets started when the cockpit-machine page loads, is located at $XDG_RUNTIME_DIR. When the virt-install (or any virt-command runs from the CLI inside the `su - admin` session, it looks at XDG_RUNTIME_DIR, and since that isn't set, it just makes up some path in ~/.cache/libvirt/
The two sockets are completely independent from each other.

Minimal reproducer:

$ virsh -c qemu:///list --all
$ env -u XDG_RUNTIME_DIR virsh -c qemu:///list --all

The above two will create two separate daemons.The first one's socket is in /run/user/1000, the second in ~/.cache/libvirt/

Comment 3 Karel Zak 2023-01-17 17:56:44 UTC
Try 'runuser - username', it uses pam_systemd on Fedora/RHEL

# grep systemd /etc/pam.d/runuser-l 
-session	optional	pam_systemd.so

Comment 5 RHEL Program Management 2023-06-17 07:29:15 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 10 Katerina Koukiou 2023-07-03 07:56:07 UTC
Closing as WONTFIX.  This issue is not reflecting some mainstream use case, and the user could use the UI and the embedded terminal with the connected user and avoid this.


Note You need to log in before you can comment on or make changes to this bug.