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.
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.
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
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.
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.
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Most likely libvirt or whoever is launching the containers is not running as root, so it is being blocked access.
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.
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
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
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
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
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
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.
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
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