libvirt users - Apr 2019 - Re: libvirtd via unix socket using system uri

On 29/04/2019 22.01, Michal Privoznik wrote:
> On 4/29/19 1:06 PM, lameventanas@gmail.com wrote:
>> I want to run libvirtd as a special user, and allowing users that
belong
>> to a special group to connect via qemu+unix:///system (eg: unix
socket).
>>
>> I did everything necessary to do so: created a libvirt user and group,
>> added the libvirt user to the kvm group, added my normal user to the
>> libvirt group, and made sure the socket is owned by libvirt:libvirt
with
>> permissions set to 770.
>>
>> libvirtd starts successfully, but when I try to connect as the normal
>> user I get this error:
>>
>> bash$ virsh --connect qemu+unix://system
>> error: failed to connect to the hypervisor
>> error: invalid argument: using unix socket and remote server
'system' is
>> not supported.
> 
> This is not valid URI.
> 
> https://libvirt.org/uri.html
> 
> You may want to use 'qemu+unix:///system' or simply
'qemu:///system'
> which is the same because libvirt connects via unix socket by default.
Thanks, I missed that.

Now I get this:

$ virsh --connect qemu:///system
error: failed to connect to the hypervisor
error: internal error: unexpected QEMU URI path '/system', try
qemu:///session

But now I see virsh opening the socket, writing, etc.

The server log shows this:

2019-04-29 15:32:07.306+0000: 20863: info : libvirt version: 5.2.0
2019-04-29 15:32:07.306+0000: 20863: info : hostname: koji
2019-04-29 15:32:07.306+0000: 20863: error : virDBusGetSessionBus:169 :
internal error: Unable to get DBus session bus connection: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
2019-04-29 15:32:24.534+0000: 20852: error : qemuConnectOpen:1127 :
internal error: unexpected QEMU URI path '/system', try qemu:///session
2019-04-29 15:32:24.534+0000: 20851: error : virNetSocketReadWire:1803 :
End of file while reading data: Input/output error

I also wonder if dbus is important, and if so, how to fix it.

> Anyway, you'll need to run libvirtd privileged, otherwise it'll get
> EPERM when trying to do almost anything.
I'm aware of that, I want to try and see the limitations, and maybe get
around them by using capabilities?

On Tue, Apr 30, 2019 at 12:42:11AM +0900, lameventanas@gmail.com
wrote:
> 
> 
> On 29/04/2019 22.01, Michal Privoznik wrote:
> > On 4/29/19 1:06 PM, lameventanas@gmail.com wrote:
> >> I want to run libvirtd as a special user, and allowing users that
belong
> >> to a special group to connect via qemu+unix:///system (eg: unix
socket).
> >>
> >> I did everything necessary to do so: created a libvirt user and
group,
> >> added the libvirt user to the kvm group, added my normal user to
the
> >> libvirt group, and made sure the socket is owned by
libvirt:libvirt with
> >> permissions set to 770.
> >>
> >> libvirtd starts successfully, but when I try to connect as the
normal
> >> user I get this error:
> >>
> >> bash$ virsh --connect qemu+unix://system
> >> error: failed to connect to the hypervisor
> >> error: invalid argument: using unix socket and remote server
'system' is
> >> not supported.
> > 
> > This is not valid URI.
> > 
> > https://libvirt.org/uri.html
> > 
> > You may want to use 'qemu+unix:///system' or simply
'qemu:///system'
> > which is the same because libvirt connects via unix socket by default.
> 
> Thanks, I missed that.
> 
> Now I get this:
> 
> $ virsh --connect qemu:///system
> error: failed to connect to the hypervisor
> error: internal error: unexpected QEMU URI path '/system', try
> qemu:///session
> 
> But now I see virsh opening the socket, writing, etc.
> 
> The server log shows this:
> 
> 2019-04-29 15:32:07.306+0000: 20863: info : libvirt version: 5.2.0
> 2019-04-29 15:32:07.306+0000: 20863: info : hostname: koji
> 2019-04-29 15:32:07.306+0000: 20863: error : virDBusGetSessionBus:169 :
> internal error: Unable to get DBus session bus connection: Unable to
> autolaunch a dbus-daemon without a $DISPLAY for X11
> 2019-04-29 15:32:24.534+0000: 20852: error : qemuConnectOpen:1127 :
> internal error: unexpected QEMU URI path '/system', try
qemu:///session
> 2019-04-29 15:32:24.534+0000: 20851: error : virNetSocketReadWire:1803 :
> End of file while reading data: Input/output error
> 
> I also wonder if dbus is important, and if so, how to fix it.
> 
> 
> > Anyway, you'll need to run libvirtd privileged, otherwise
it'll get
> > EPERM when trying to do almost anything.
> 
> I'm aware of that, I want to try and see the limitations, and maybe get
> around them by using capabilities?
Libvirt has two distinct modes of operation - system mode and session
mode. When uid == 0, libvirtd runs in system mode & offers full
privileges. When uid != 0 it runs in session mode & disables alot of
functionality, or it will simply fail to use it.

It is impossible to run system mode as uid != 0, as it will always
activate session mode in this case.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 4/29/19 5:42 PM, lameventanas@gmail.com wrote:
> 
> 
> On 29/04/2019 22.01, Michal Privoznik wrote:
>> On 4/29/19 1:06 PM, lameventanas@gmail.com wrote:
>>> I want to run libvirtd as a special user, and allowing users that
belong
>>> to a special group to connect via qemu+unix:///system (eg: unix
socket).
>>>
>>> I did everything necessary to do so: created a libvirt user and
group,
>>> added the libvirt user to the kvm group, added my normal user to
the
>>> libvirt group, and made sure the socket is owned by libvirt:libvirt
with
>>> permissions set to 770.
>>>
>>> libvirtd starts successfully, but when I try to connect as the
normal
>>> user I get this error:
>>>
>>> bash$ virsh --connect qemu+unix://system
>>> error: failed to connect to the hypervisor
>>> error: invalid argument: using unix socket and remote server
'system' is
>>> not supported.
>>
>> This is not valid URI.
>>
>> https://libvirt.org/uri.html
>>
>> You may want to use 'qemu+unix:///system' or simply
'qemu:///system'
>> which is the same because libvirt connects via unix socket by default.
> 
> Thanks, I missed that.
> 
> Now I get this:
> 
> $ virsh --connect qemu:///system
> error: failed to connect to the hypervisor
> error: internal error: unexpected QEMU URI path '/system', try
> qemu:///session
> 
> But now I see virsh opening the socket, writing, etc.
> 
> The server log shows this:
> 
> 2019-04-29 15:32:07.306+0000: 20863: info : libvirt version: 5.2.0
> 2019-04-29 15:32:07.306+0000: 20863: info : hostname: koji
> 2019-04-29 15:32:07.306+0000: 20863: error : virDBusGetSessionBus:169 :
> internal error: Unable to get DBus session bus connection: Unable to
> autolaunch a dbus-daemon without a $DISPLAY for X11
> 2019-04-29 15:32:24.534+0000: 20852: error : qemuConnectOpen:1127 :
> internal error: unexpected QEMU URI path '/system', try
qemu:///session
> 2019-04-29 15:32:24.534+0000: 20851: error : virNetSocketReadWire:1803 :
> End of file while reading data: Input/output error
> 
> I also wonder if dbus is important, and if so, how to fix it.
This happened because qemu driver for /system doesn't initialize unless 
libvirtd's EUID == 0.
> 
> 
>> Anyway, you'll need to run libvirtd privileged, otherwise it'll
get
>> EPERM when trying to do almost anything.
> 
> I'm aware of that, I want to try and see the limitations, and maybe get
> around them by using capabilities?
> 
Is there any problem running libvirtd as root?

Michal

On Tue, 30 Apr 2019 at 10:40, Michal Privoznik <mprivozn@redhat.com>
wrote:
> Is there any problem running libvirtd as root?
>
> Yes, in the regulated environment in which I work!  I have to do far more
thorough threat analysis than I would do if I knew which capabilities it
had.  So far, we've accepted the extra work; but it would be wonderful to
be able to run a locked-down virtualisation environment.

Cheers,

- Peter