3:09 p.m.
Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
Currently if you install a minimal-ish, non-"Virtualization Host"
Fedora, then the permissions on the /dev/kvm device are:
crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
(I believe this is because of some kernel defaults for the device. In
any case there seems to be no base install udev rule which applies a
`MODE=' line explicitly for /dev/kvm).
There mere act of installing the qemu package adds a new udev rule
which changes the permissions:
[root@rawhide ~]# ll /dev/kvm
crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
[root@rawhide ~]# dnf -y install qemu-system-x86
//...
[root@rawhide ~]# ll /dev/kvm
crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
I don't have a problem with any of that and I'm not saying that the
permissions should be more restrictive, but for balance I will note
that in Debian /dev/kvm is more restrictive (see comment in the bug
above).
The problem raised in the bug above is that with containers people
will wish to install qemu or libvirt or other tools inside the
containers, but not necessarily have qemu installed on the host. In
that case, they will always see /dev/kvm with mode 0600, ie. generally
unusable for them.
Should we include the qemu udev rule [to make /dev/kvm 0666] in the
base RHEL install? Or something else?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
3:20 p.m.
On Tue, Mar 14, 2017 at 08:09:00PM +0000, Richard W.M. Jones wrote:
base RHEL install? Or something else?
Bleah yes I've been spending too long today doing RHEL security fixes.
I meant of course the base _Fedora_ install.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3:29 p.m.
On Tue, Mar 14, 2017 at 08:09:00PM +0000, Richard W.M. Jones wrote:
Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
Currently if you install a minimal-ish, non-"Virtualization Host"
Fedora, then the permissions on the /dev/kvm device are:
crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
(I believe this is because of some kernel defaults for the device. In
any case there seems to be no base install udev rule which applies a
`MODE=' line explicitly for /dev/kvm).
There mere act of installing the qemu package adds a new udev rule
which changes the permissions:
[root@rawhide ~]# ll /dev/kvm
crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
[root@rawhide ~]# dnf -y install qemu-system-x86
//...
[root@rawhide ~]# ll /dev/kvm
crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
I don't have a problem with any of that and I'm not saying that the
permissions should be more restrictive, but for balance I will note
that in Debian /dev/kvm is more restrictive (see comment in the bug
above).
The problem raised in the bug above is that with containers people
will wish to install qemu or libvirt or other tools inside the
containers, but not necessarily have qemu installed on the host. In
that case, they will always see /dev/kvm with mode 0600, ie. generally
unusable for them.
I'm fuzzy about the issue faced with containers. Containers will usually
have a separate /dev that is populated by the container mgmt engine (whether
docker, libvirt, lxc or something else). That mgmt engine is responsible for
setting permissions of /dev/kvm in the container's /dev if the user asked for
/dev/kvm to be made available. udev should never run inside a container - it
is only supposed to run in host context. So any udev rules that manipulate
/dev/kvm permissions will only ever be used in host context and never have
any effect on containers.
The bug listed above doesn't actually describe any real problem with
containers & /dev/kvm - my reading is that the bug is just thinking
about a hypothetical future problem, but since udev isn't involved
in containers' /dev mgmt, I don't think there's a bug that needs fixing
here.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
3:56 p.m.
On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
On Tue, Mar 14, 2017 at 08:09:00PM +0000, Richard W.M. Jones wrote:
> Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
>
> Currently if you install a minimal-ish, non-"Virtualization Host"
> Fedora, then the permissions on the /dev/kvm device are:
>
> crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>
> (I believe this is because of some kernel defaults for the device. In
> any case there seems to be no base install udev rule which applies a
> `MODE=' line explicitly for /dev/kvm).
>
> There mere act of installing the qemu package adds a new udev rule
> which changes the permissions:
>
> [root@rawhide ~]# ll /dev/kvm
> crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> [root@rawhide ~]# dnf -y install qemu-system-x86
> //...
> [root@rawhide ~]# ll /dev/kvm
> crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>
> I don't have a problem with any of that and I'm not saying that the
> permissions should be more restrictive, but for balance I will note
> that in Debian /dev/kvm is more restrictive (see comment in the bug
> above).
>
> The problem raised in the bug above is that with containers people
> will wish to install qemu or libvirt or other tools inside the
> containers, but not necessarily have qemu installed on the host. In
> that case, they will always see /dev/kvm with mode 0600, ie. generally
> unusable for them.
I'm fuzzy about the issue faced with containers. Containers will usually
have a separate /dev that is populated by the container mgmt engine (whether
docker, libvirt, lxc or something else). That mgmt engine is responsible for
setting permissions of /dev/kvm in the container's /dev if the user asked for
/dev/kvm to be made available. udev should never run inside a container - it
is only supposed to run in host context. So any udev rules that manipulate
/dev/kvm permissions will only ever be used in host context and never have
any effect on containers.
The bug listed above doesn't actually describe any real problem with
containers & /dev/kvm - my reading is that the bug is just thinking
about a hypothetical future problem, but since udev isn't involved
in containers' /dev mgmt, I don't think there's a bug that needs fixing
here.
Regards,
Daniel
I guess if you volume/bind mount the device into the container you could
see an issue,
but most containers that deal with /dev/kvm are going to be run as root,
anyways.
4:01 p.m.
On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
I'm fuzzy about the issue faced with containers. Containers will usually
have a separate /dev that is populated by the container mgmt engine (whether
docker, libvirt, lxc or something else). That mgmt engine is responsible for
setting permissions of /dev/kvm in the container's /dev if the user asked for
/dev/kvm to be made available. udev should never run inside a container - it
is only supposed to run in host context. So any udev rules that manipulate
/dev/kvm permissions will only ever be used in host context and never have
any effect on containers.
The bug listed above doesn't actually describe any real problem with
containers & /dev/kvm - my reading is that the bug is just thinking
about a hypothetical future problem, but since udev isn't involved
in containers' /dev mgmt, I don't think there's a bug that needs fixing
here.
$user here.
The problem was real, but I don't know how legitimate the need for
change is. I opened the bug so that we could have a discussion about
it.
Basically as a user that wants to run libvirt inside a container I was
facing issues (permission denied). I noticed randomly that if I had
installed qemu on the host before I tried to run libvirt inside of a
container everything was fine. If I started from a fresh system (no
qemu ever installed on the host) and tried to run that same container,
I could not do it. Cole Robinson helped me track down that it was a
permissions issue on /dev/kvm itself. Then I found the permission
fixup code in the qemu rpm, which led me to think it might be better
to open up the permissions even if qemu is not installed so that
containerized libvirt use cases could succeed without having to
workaround it.
To workaround the person starting the container would need to change
perms on /dev/kvm or have the container do that itself before running
libvirt. I'm just saying that if we put this "hack" in qemu, then it
seems like we might as well have it outside of qemu so that the 'qemu
is delivered by a container' use case can work.
Dusty
4:02 p.m.
On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
I guess if you volume/bind mount the device into the container you could
see an issue,
but most containers that deal with /dev/kvm are going to be run as root,
anyways.
I was running with --privileged, still got permission denied until I
changed permissions of /dev/kvm to 666.
4:15 p.m.
On 03/14/2017 05:02 PM, Dusty Mabe wrote:
On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>
> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
> I guess if you volume/bind mount the device into the container you could
> see an issue,
> but most containers that deal with /dev/kvm are going to be run as root,
> anyways.
I was running with --privileged, still got permission denied until I
changed permissions of /dev/kvm to 666.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232 Mar 14 21:12
/dev/kvm
# chmod 600 /dev/kvm
# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232 Mar 14 21:13
/dev/kvm
So using --device to add the device to the container just maintains the permission of the
host
for the device you added. Whether it is volume mounted in or specified via --device, at
least
from dockers point of view.
4:18 p.m.
On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>
> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>
>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>> I guess if you volume/bind mount the device into the container you could
>> see an issue,
>> but most containers that deal with /dev/kvm are going to be run as root,
>> anyways.
> I was running with --privileged, still got permission denied until I
> changed permissions of /dev/kvm to 666.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232 Mar 14
21:12 /dev/kvm
# chmod 600 /dev/kvm
# docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232 Mar 14
21:13 /dev/kvm
So using --device to add the device to the container just maintains the permission of the
host
for the device you added. Whether it is volume mounted in or specified via --device, at
least
from dockers point of view.
I'm not sure of your point. I was just trying to say that whether i
was root or not did not seem to matter. I still got permission denied
if perms were 600 and not 666. I'm working off of memory here, so it's
possible somebody will prove me wrong.
Dusty
4:35 p.m.
On 03/14/2017 05:18 PM, Dusty Mabe wrote:
On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
>
> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>>> I guess if you volume/bind mount the device into the container you could
>>> see an issue,
>>> but most containers that deal with /dev/kvm are going to be run as root,
>>> anyways.
>> I was running with --privileged, still got permission denied until I
>> changed permissions of /dev/kvm to 666.
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232 Mar 14
21:12 /dev/kvm
> # chmod 600 /dev/kvm
> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
> crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232 Mar 14
21:13 /dev/kvm
>
> So using --device to add the device to the container just maintains the permission of
the host
> for the device you added. Whether it is volume mounted in or specified via --device,
at least
> from dockers point of view.
I'm not sure of your point. I was just trying to say that whether i
was root or not did not seem to matter. I still got permission denied
if perms were 600 and not 666. I'm working off of memory here, so it's
possible somebody will prove me wrong.
Dusty
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Most likely
libvirt or whoever is launching the containers is not running
as root, so it is being blocked access.
6:38 p.m.
On Tue, Mar 14, 2017 at 08:29:00PM +0000, Daniel P. Berrange wrote:
On Tue, Mar 14, 2017 at 08:09:00PM +0000, Richard W.M. Jones wrote:
> Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
>
> Currently if you install a minimal-ish, non-"Virtualization Host"
> Fedora, then the permissions on the /dev/kvm device are:
>
> crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>
> (I believe this is because of some kernel defaults for the device. In
> any case there seems to be no base install udev rule which applies a
> `MODE=' line explicitly for /dev/kvm).
>
> There mere act of installing the qemu package adds a new udev rule
> which changes the permissions:
>
> [root@rawhide ~]# ll /dev/kvm
> crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> [root@rawhide ~]# dnf -y install qemu-system-x86
> //...
> [root@rawhide ~]# ll /dev/kvm
> crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>
> I don't have a problem with any of that and I'm not saying that the
> permissions should be more restrictive, but for balance I will note
> that in Debian /dev/kvm is more restrictive (see comment in the bug
> above).
>
> The problem raised in the bug above is that with containers people
> will wish to install qemu or libvirt or other tools inside the
> containers, but not necessarily have qemu installed on the host. In
> that case, they will always see /dev/kvm with mode 0600, ie. generally
> unusable for them.
I'm fuzzy about the issue faced with containers. Containers will usually
have a separate /dev that is populated by the container mgmt engine (whether
docker, libvirt, lxc or something else). That mgmt engine is responsible for
setting permissions of /dev/kvm in the container's /dev if the user asked for
/dev/kvm to be made available. udev should never run inside a container - it
is only supposed to run in host context. So any udev rules that manipulate
/dev/kvm permissions will only ever be used in host context and never have
any effect on containers.
The bug listed above doesn't actually describe any real problem with
containers & /dev/kvm - my reading is that the bug is just thinking
about a hypothetical future problem, but since udev isn't involved
in containers' /dev mgmt, I don't think there's a bug that needs fixing
here.
This applies to any system where kvm is to be used by unprivileged users
without qemu package being installed. It is possible to use kvm in this
way, e.g. by using self-compiled qemu, or some alternative or whatever.
So maybe we should move the rules for /dev/kvm to
/usr/lib/udev/rules.d/50-udev-default.rules.
Zbyszek
4:17 a.m.
On Tue, Mar 14, 2017 at 11:38:51PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 14, 2017 at 08:29:00PM +0000, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 08:09:00PM +0000, Richard W.M. Jones wrote:
> > Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
> >
> > Currently if you install a minimal-ish, non-"Virtualization Host"
> > Fedora, then the permissions on the /dev/kvm device are:
> >
> > crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> >
> > (I believe this is because of some kernel defaults for the device. In
> > any case there seems to be no base install udev rule which applies a
> > `MODE=' line explicitly for /dev/kvm).
> >
> > There mere act of installing the qemu package adds a new udev rule
> > which changes the permissions:
> >
> > [root@rawhide ~]# ll /dev/kvm
> > crw-------. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > [root@rawhide ~]# dnf -y install qemu-system-x86
> > //...
> > [root@rawhide ~]# ll /dev/kvm
> > crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> >
> > I don't have a problem with any of that and I'm not saying that the
> > permissions should be more restrictive, but for balance I will note
> > that in Debian /dev/kvm is more restrictive (see comment in the bug
> > above).
> >
> > The problem raised in the bug above is that with containers people
> > will wish to install qemu or libvirt or other tools inside the
> > containers, but not necessarily have qemu installed on the host. In
> > that case, they will always see /dev/kvm with mode 0600, ie. generally
> > unusable for them.
>
> I'm fuzzy about the issue faced with containers. Containers will usually
> have a separate /dev that is populated by the container mgmt engine (whether
> docker, libvirt, lxc or something else). That mgmt engine is responsible for
> setting permissions of /dev/kvm in the container's /dev if the user asked for
> /dev/kvm to be made available. udev should never run inside a container - it
> is only supposed to run in host context. So any udev rules that manipulate
> /dev/kvm permissions will only ever be used in host context and never have
> any effect on containers.
>
> The bug listed above doesn't actually describe any real problem with
> containers & /dev/kvm - my reading is that the bug is just thinking
> about a hypothetical future problem, but since udev isn't involved
> in containers' /dev mgmt, I don't think there's a bug that needs fixing
> here.
This applies to any system where kvm is to be used by unprivileged users
without qemu package being installed. It is possible to use kvm in this
way, e.g. by using self-compiled qemu, or some alternative or whatever.
So maybe we should move the rules for /dev/kvm to
/usr/lib/udev/rules.d/50-udev-default.rules.
Sure, if udev maintainers are willing to ship the kvm rule by default,
that's fine with me for reason you suggest. I simply don't think it'll
have any effect on usage of /dev/kvm inside containers
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
4:27 a.m.
On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>
> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>>>> I guess if you volume/bind mount the device into the container you
could
>>>> see an issue,
>>>> but most containers that deal with /dev/kvm are going to be run as
root,
>>>> anyways.
>>> I was running with --privileged, still got permission denied until I
>>> changed permissions of /dev/kvm to 666.
>>> _______________________________________________
>>> devel mailing list -- devel(a)lists.fedoraproject.org
>>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232
Mar 14 21:12 /dev/kvm
>> # chmod 600 /dev/kvm
>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>> crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232
Mar 14 21:13 /dev/kvm
>>
>> So using --device to add the device to the container just maintains the
permission of the host
>> for the device you added. Whether it is volume mounted in or specified via
--device, at least
>> from dockers point of view.
> I'm not sure of your point. I was just trying to say that whether i
> was root or not did not seem to matter. I still got permission denied
> if perms were 600 and not 666. I'm working off of memory here, so it's
> possible somebody will prove me wrong.
Most likely libvirt or whoever is launching the containers is not running
as root, so it is being blocked access.
It is simpler than that. When you ask libvirt to assign a device to a
container it will simply mknod() in the container's private /dev, with
permissions 0700. If the container needs to make that available to
mon-privileged users inside the container, its "init" has to arrange
to set permissions further.
For Docker, I'm unclear whether it is also just doing a mknod in the
container's /dev, or whether it is bind mounting the host device node.
Either way, udev isn't involved inside the container.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
6:47 a.m.
On 03/15/2017 05:27 AM, Daniel P. Berrange wrote:
On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>
> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
>>> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
>>>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
>>>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
>>>>> I guess if you volume/bind mount the device into the container you
could
>>>>> see an issue,
>>>>> but most containers that deal with /dev/kvm are going to be run as
root,
>>>>> anyways.
>>>> I was running with --privileged, still got permission denied until I
>>>> changed permissions of /dev/kvm to 666.
>>>> _______________________________________________
>>>> devel mailing list -- devel(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>>> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 232
Mar 14 21:12 /dev/kvm
>>> # chmod 600 /dev/kvm
>>> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
>>> crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 232
Mar 14 21:13 /dev/kvm
>>>
>>> So using --device to add the device to the container just maintains the
permission of the host
>>> for the device you added. Whether it is volume mounted in or specified via
--device, at least
>>> from dockers point of view.
>> I'm not sure of your point. I was just trying to say that whether i
>> was root or not did not seem to matter. I still got permission denied
>> if perms were 600 and not 666. I'm working off of memory here, so it's
>> possible somebody will prove me wrong.
> Most likely libvirt or whoever is launching the containers is not running
> as root, so it is being blocked access.
It is simpler than that. When you ask libvirt to assign a device to a
container it will simply mknod() in the container's private /dev, with
permissions 0700. If the container needs to make that available to
mon-privileged users inside the container, its "init" has to arrange
to set permissions further.
For Docker, I'm unclear whether it is also just doing a mknod in the
container's /dev, or whether it is bind mounting the host device node.
Either way, udev isn't involved inside the container.
Regards,
Daniel
My point was that docker is just matching the permissions from the host.
In the case of using docker run --device /dev/kvm
It is creating a different device
#ls -i /dev/kvm
18835 /dev/kvm
# docker run -ti --device /dev/kvm fedora sh
# ls -lZ /dev/kvm
crw-------. 1 root 36 system_u:object_r:container_file_t:s0:c516,c728 10, 232 Mar 15 11:44
/dev/kvm
# ls -i /dev/kvm
669570 /dev/kvm
If I chmod 666 outside of the container the mode of the container is still 600, so they
are different devices.
10:32 a.m.
On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
Sure, if udev maintainers are willing to ship the kvm rule by default,
that's fine with me for reason you suggest. I simply don't think it'll
have any effect on usage of /dev/kvm inside containers
Does that mean you assume my scenario I outlined is incorrect? The
only reason we are having this discussion is because i found that
changing the permissions of /dev/kvm on the host from 600 to 666 made
it so that I could run libvirt inside a container, which would mean
that if does have an effect on usage of /dev/kvm inside a container.
I could be "using it wrong", but would like for you to tell me why
what I'm doing is invalid.
Dusty
10:49 a.m.
On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>
> Sure, if udev maintainers are willing to ship the kvm rule by default,
> that's fine with me for reason you suggest. I simply don't think it'll
> have any effect on usage of /dev/kvm inside containers
>
Does that mean you assume my scenario I outlined is incorrect? The
only reason we are having this discussion is because i found that
changing the permissions of /dev/kvm on the host from 600 to 666 made
it so that I could run libvirt inside a container, which would mean
that if does have an effect on usage of /dev/kvm inside a container.
Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.
I could be "using it wrong", but would like for you to tell
me why
what I'm doing is invalid.
While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.
IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).
I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
11:37 a.m.
On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>> that's fine with me for reason you suggest. I simply don't think
it'll
>> have any effect on usage of /dev/kvm inside containers
>>
> Does that mean you assume my scenario I outlined is incorrect? The
> only reason we are having this discussion is because i found that
> changing the permissions of /dev/kvm on the host from 600 to 666 made
> it so that I could run libvirt inside a container, which would mean
> that if does have an effect on usage of /dev/kvm inside a container.
Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.
> I could be "using it wrong", but would like for you to tell me why
> what I'm doing is invalid.
While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.
IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).
I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host.
Regards,
Daniel
Lets open a bugzilla on this for docker, although I am not sure upstream
would be amenable to a decent solution.
7:20 p.m.
As part of the discussion at the systemd bugtracker [1], people from
Debian said that they prefer 0660 mode, group kvm, because this limits
the exposure to kernel bugs in the kvm module. Those are not frequent,
but they do happen, so it's hard to argue that increases security at
least a bit.
Currently, kvm is tagged with uaccess, so locally logged in users
also get access to /dev/kvm, no matter what the access mode is.
With the 0660 mode, users (not locally logged in) need to be added
to kvm group to get access. Would such a mode where one need to either
log in locally, or be root, or be in the kvm group work for Fedora?
[1] https://github.com/systemd/systemd/pull/5597
Zbyszek
8:30 a.m.
On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>
>
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>>
>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>> that's fine with me for reason you suggest. I simply don't think
it'll
>> have any effect on usage of /dev/kvm inside containers
>>
>
> Does that mean you assume my scenario I outlined is incorrect? The
> only reason we are having this discussion is because i found that
> changing the permissions of /dev/kvm on the host from 600 to 666 made
> it so that I could run libvirt inside a container, which would mean
> that if does have an effect on usage of /dev/kvm inside a container.
Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.
right
> I could be "using it wrong", but would like for you to
tell me why
> what I'm doing is invalid.
While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.
IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).
I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host.
Thanks for the explanation. Maybe we should just leave things like
they are in Fedora then and not worry with changing systemd since it
looks like we won't be able to get them to change it to 666 by default
anyway.
Should we just cancel our request? I think any change other than 666
perms would probably cause more problems than it would solve.
Dusty
2604
days inactive
2607
days old
17 comments
5 participants
participants (5)
-
Daniel J Walsh -
Daniel P. Berrange -
Dusty Mabe -
Richard W.M. Jones -
Zbigniew Jędrzejewski-Szmek