Add user ACLs for /dev/rfkill
From 6e4ceb8205a7027b750d0cf1477834e91341e502 Mon Sep 17 00:00:00 2001
From: Harald Hoyer <[email protected]>
Date: Fri, 31 Jul 2009 12:55:49 +0200
Subject: [PATCH] 70-acl.rules: add rfkill switch
For gnome-bluetooth's killswitch code to work, the user on the local console needs to have access to /dev/rfkill.
see https://bugzilla.redhat.com/show_bug.cgi?id=514798
--- extras/udev-acl/70-acl.rules | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
extras/udev-acl/70-acl.rules +3 -0
@@ -44,6 +44,9 @@ SUBSYSTEM=="misc", KERNEL=="kvm", ENV{ACL_MANAGE}="1" # smart-card readers ENV{ID_SMARTCARD_READER}=="*?", ENV{ACL_MANAGE}="1" +# rfkill switch +KERNEL=="rfkill", ENV{ACL_MANAGE}="1" + # apply ACL for all locally logged in users LABEL="acl_apply", ENV{ACL_MANAGE}=="?*", TEST=="/var/run/ConsoleKit/database", \ RUN+="udev-acl --action=$env{ACTION} --device=$env{DEVNAME}"
Signature · 1 line
1.6.2.5
Hi Harald,
Quoted 4 lines
From
6e4ceb8205a7027b750d0cf1477834e91341e502Mon Sep 17 00:00:00 2001
From: Harald Hoyer <[email protected]>
Date: Fri, 31 Jul 2009 12:55:49 +0200
Subject: [PATCH] 70-acl.rules: add rfkill switch
do you mind using git send-email instead of just attaching the patch without any email body.
Quoted 18 lines
For gnome-bluetooth's killswitch code to work, the user on the local console needs to have access to
/dev/rfkill.see https://bugzilla.redhat.com/show_bug.cgi?idQ4798
--- extras/udev-acl/70-acl.rules | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)extras/udev-acl/70-acl.rules +0
-0@@ -44,6 +44,9 @@ SUBSYSTEM="misc", KERNEL="kvm",ENV{ACL_MANAGE}="1"
# smart-card readers ENV{ID_SMARTCARD_READER}="*?", ENV{ACL_MANAGE}="1"
extras/udev-acl/70-acl.rules SUBSYSTEM=="misc", KERNEL=="kvm", ENV{ACL_MANAGE}="1" · line 49
Quoted 3 lines
extras/udev-acl/70-acl.rules +3
-0+# rfkill switch +KERNEL="rfkill", ENV{ACL_MANAGE}="1" +
I am not convinced this is the right way to do. Exposing the RFKILL control to the console user might be wrong.
Regards
Marcel
Kay?
Quoted 1 line · Harald Hoyer
Kay?
What's the use case and unprivileged user will need this? It's more that NetworkManager and such will interact with that, right?
Kay
Quoted 5 lines · Kay Sievers
Quoted 1 line · Harald Hoyer
Kay?
What's the use case and unprivileged user will need this? It's more that NetworkManager and such will interact with that, right?
The bluetooth radio itself is not necessarily a NM-managed object; it's managed by gnome-bluetooth or similar stacks.
My concern about making it user accesible is it makes it harder for an administrator to lock down the device if the user can then just unlock it. But perhaps that's better done at the modprobe level (not that that works sanely now.)
Bill
Hi Bill,
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Kay?
What's the use case and unprivileged user will need this? It's more that NetworkManager and such will interact with that, right?
The bluetooth radio itself is not necessarily a NM-managed object; it's managed by gnome-bluetooth or similar stacks.
the Bluetooth radio is not managed by gnome-bluetooth. It is managed by bluetoothd. The gnome-bluetooth is just UI code. I object against having UI code control RFKILL switches directly without proper policy and access management in between.
Quoted 4 lines
My concern about making it user accesible is it makes it harder for an administrator to lock down the device if the user can then just unlock it. But perhaps that's better done at the modprobe level (not that that works sanely now.)
Exactly. We can not just give a user control over all RFKILL switches. If you wanna do that in a generic way, you better have a D-Bus enabled RFKILL daemon that integrates with PolicyKit or use something like ConnMan which already does this.
Regards
Marcel