Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] Conflicting udev rules shipped for KVM
@ 2019-09-13 20:30 voidlinux-github
  2019-09-14  8:12 ` voidlinux-github
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-13 20:30 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

New issue by thomas-t-w on void-packages repository

https://github.com/void-linux/void-packages/issues/14440

Description:
eudev ships 50-default.rules which contains
KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"
base-files shipps 66-kvm.rules which contains
KERNEL=="kvm", GROUP="kvm", MODE="0660"

If I had to make a decision, I would vote for 0660 and require users to add themselves to the kvm group but that is only because I am not qualified to speak about the security implications of letting everyone access the kvm module. We could always print an install message for qemu telling users they had to add themselves to the kvm group. I would like to let someone who knows more about this make the final decision though.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Conflicting udev rules shipped for KVM
  2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
@ 2019-09-14  8:12 ` voidlinux-github
  2019-09-14  9:50 ` voidlinux-github
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-14  8:12 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

New comment by Hoshpak on void-packages repository

https://github.com/void-linux/void-packages/issues/14440#issuecomment-531460441

Comment:
I'm not sure if that is an issue at all. The rule from base-files has a higher number so it is evaluated after the udev default rule and overrides it. I just checked on my system and the permissions are indeed set to 0660. The static_node options is required on some systems according to the comment in the code and udev doesn't see it as a conflict and just overrides the earlier permissions.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Conflicting udev rules shipped for KVM
  2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
  2019-09-14  8:12 ` voidlinux-github
@ 2019-09-14  9:50 ` voidlinux-github
  2019-09-14 11:53 ` voidlinux-github
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-14  9:50 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

New comment by thomas-t-w on void-packages repository

https://github.com/void-linux/void-packages/issues/14440#issuecomment-531466399

Comment:
I initially thought that as well actually but it is very strange for me. When I first reboot my system, my permissions on /dev/kvm start out as 0666. After the first time that I run qemu, they change to 0660. If I remove one of the rules, they stay at the permissions that the other rule set even if I run Qemu multiple times. Can you see what your rule is right after reboot? Maybe eudev is getting stuck for some reason on my system and this is uncommon in which case we could just close this.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Conflicting udev rules shipped for KVM
  2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
  2019-09-14  8:12 ` voidlinux-github
  2019-09-14  9:50 ` voidlinux-github
@ 2019-09-14 11:53 ` voidlinux-github
  2019-09-14 13:55 ` voidlinux-github
  2019-09-16 14:20 ` [ISSUE] [CLOSED] " voidlinux-github
  4 siblings, 0 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-14 11:53 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

New comment by Hoshpak on void-packages repository

https://github.com/void-linux/void-packages/issues/14440#issuecomment-531473672

Comment:
Indeed, I tried on my second Void installation and it had /dev/kvm set to 0666 after a system boot. It was probably libvirt on my first installation that touched the device that touched the device and thus lead to udev setting the correct permissions.

I experimented a bit with it and if I comment out the udev default rule, the permissions get applied correctly. If I remove both rules, the default is root:root and 0600. Not really finding an explanation why the second rule seems to be ignored on boot I thought it might be because the first one is more specific and the rules don't match exactly. I'm still not sure if that is the cause but either removing `OPTIONS+="static_node=kvm"` from the first rule oder adding it to the second rule leads to both rules being executed during udev startup and it works as expected.  

While we could just patch the udev default rules, I think it would be better to change the base-files rule so the default one gets properly overridden.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Conflicting udev rules shipped for KVM
  2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
                   ` (2 preceding siblings ...)
  2019-09-14 11:53 ` voidlinux-github
@ 2019-09-14 13:55 ` voidlinux-github
  2019-09-16 14:20 ` [ISSUE] [CLOSED] " voidlinux-github
  4 siblings, 0 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-14 13:55 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

New comment by thomas-t-w on void-packages repository

https://github.com/void-linux/void-packages/issues/14440#issuecomment-531481665

Comment:
I agree. I will create a pull request for that adding those options to our base files. I did some research and kvm is created as a static node in eudev because the module isn't loaded on some platforms until first use. Best not to patch the rules file in eudev because that could change from time to time in eudev and because we probably want to keep it as a static node.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [ISSUE] [CLOSED] Conflicting udev rules shipped for KVM
  2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
                   ` (3 preceding siblings ...)
  2019-09-14 13:55 ` voidlinux-github
@ 2019-09-16 14:20 ` voidlinux-github
  4 siblings, 0 replies; 6+ messages in thread
From: voidlinux-github @ 2019-09-16 14:20 UTC (permalink / raw)
  To: ml

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Closed issue by thomas-t-w on void-packages repository

https://github.com/void-linux/void-packages/issues/14440

Description:
eudev ships 50-default.rules which contains
KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"
base-files shipps 66-kvm.rules which contains
KERNEL=="kvm", GROUP="kvm", MODE="0660"

If I had to make a decision, I would vote for 0660 and require users to add themselves to the kvm group but that is only because I am not qualified to speak about the security implications of letting everyone access the kvm module. We could always print an install message for qemu telling users they had to add themselves to the kvm group. I would like to let someone who knows more about this make the final decision though.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-09-16 14:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-13 20:30 [ISSUE] Conflicting udev rules shipped for KVM voidlinux-github
2019-09-14  8:12 ` voidlinux-github
2019-09-14  9:50 ` voidlinux-github
2019-09-14 11:53 ` voidlinux-github
2019-09-14 13:55 ` voidlinux-github
2019-09-16 14:20 ` [ISSUE] [CLOSED] " voidlinux-github

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).