Add user ACLs for /dev/rfkill

Add user ACLs for /dev/rfkill

[Harald Hoyer]

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



[-- Attachment #2: 0001-70-acl.rules-add-rfkill-switch.patch --]
[-- Type: text/plain, Size: 1049 bytes --]

From 6e4ceb8205a7027b750d0cf1477834e91341e502 Mon Sep 17 00:00:00 2001
From: Harald Hoyer <harald@redhat.com>
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(-)

diff --git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index f41bb66..85ea8a1 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -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}"
-- 
1.6.2.5

Re: Add user ACLs for /dev/rfkill

[Marcel Holtmann]

Hi Harald,

> From 6e4ceb8205a7027b750d0cf1477834e91341e502 Mon Sep 17 00:00:00 2001
> From: Harald Hoyer <harald@redhat.com>
> 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.

> 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(-)
> 
> diff --git a/extras/udev-acl/70-acl.rules
> b/extras/udev-acl/70-acl.rules
> index f41bb66..85ea8a1 100644
> --- a/extras/udev-acl/70-acl.rules
> +++ b/extras/udev-acl/70-acl.rules
> @@ -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"
> +

I am not convinced this is the right way to do. Exposing the RFKILL
control to the console user might be wrong.

Regards

Marcel

Re: Add user ACLs for /dev/rfkill

[Harald Hoyer]

Kay?

Re: Add user ACLs for /dev/rfkill

[Kay Sievers]

On Fri, Aug 7, 2009 at 14:27, Harald Hoyer<harald@redhat.com> wrote:
> 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

Re: Add user ACLs for /dev/rfkill

[Bill Nottingham]

Kay Sievers (kay.sievers@vrfy.org) said: 
> On Fri, Aug 7, 2009 at 14:27, Harald Hoyer<harald@redhat.com> wrote:
> > 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

Re: Add user ACLs for /dev/rfkill

[Marcel Holtmann]

Hi Bill,

> > > 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.

> 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