# Need dbus rule for access to battery.

## curmudgeon

In kde:

```

# solid-hardware query 'IS Battery'

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0'

$ solid-hardware query 'IS Battery'

QStringList Solid::Backends::Hal::HalManager::findDeviceByDeviceInterface(const Solid::DeviceInterface::Type&)  error:  "org.freedesktop.DBus.Error.AccessDenied"

```

I would like to modify the configuration files to give ordinary users access to the battery (it seems silly to me to deny this).

I have spent a fair amount of time looking through the config files, and they seem like greek to me (actually, I think I could do better with greek).

Does anyone know the right modification to make for battery access?

Thank you in advance.

----------

## ewaller

I think you can achieve what you want by adding your users to the hal group.  Or did you want the granularity to allow access to the battery, but not other hal functions?

----------

## albright

Just FYI, ordinary users on my computer can run that command:

```
$ solid-hardware query 'IS Battery'

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0'

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT1'
```

But - note - I have the PAM enabled hal/solid/kde and, as I recall, that is what

you want to avoid. It's possible you're hitting the same roadblock here.

----------

## curmudgeon

 *ewaller wrote:*   

> I think you can achieve what you want by adding your users to the hal group.  Or did you want the granularity to allow access to the battery, but not other hal functions?

 

I have no idea what the other hal functions are, but in any case, the users are members of both the haldaemon group and the plugdev group, and still can't access the battery.

----------

## curmudgeon

 *albright wrote:*   

> But - note - I have the PAM enabled hal/solid/kde and, as I recall, that is what
> 
> you want to avoid. It's possible you're hitting the same roadblock here.

 

Pam should not be REQUIRED to access the battery. That would be a completely moronic design (though I have seen similar things in the past).

It still seems (based on my limited knowledge, though I could be wrong) that a dbus rule could allow access.

Actually dbus is starting to look like pam - ridiculously complex, and all but impossible for ordinary users to accomplish anything with.

----------

## ewaller

On this system:

```
ewaller@odin:~ 1004 %solid-hardware query 'IS Battery'

udi = '/org/freedesktop/Hal/devices/computer_power_supply_battery_BAT0'

ewaller@odin:~ 1005 %
```

and:

```
ewaller@odin:~ 1005 %groups 

wheel audio cdrom video games cdrw apache usb users vboxusers wireshark plugdev haldaemon lpadmin polkituser ewaller

ewaller@odin:~ 1006 %
```

How do you start your kde session?

----------

## curmudgeon

 *ewaller wrote:*   

> How do you start your kde session?

 

I have xdm in the default runlevel with DISPLAYMANAGER='kdm' in /etc/conf.d/xdm.

----------

## ewaller

 *curmudgeon wrote:*   

> I have xdm in the default runlevel with DISPLAYMANAGER='kdm' in /etc/conf.d/xdm.

 

Well, that should pretty well set up dbus for your user.

I ran dbus-monitor on my system and noted that the solid-hardware query does not actually generate any dbus activity -- Not what I expected :/   Then I started to think; What do you mean by "Battery Access"?  Can your users see the contents of the /proc and /sys trees?  Beyond seeing the state and info of the batteries in /proc/acpi/battery/BATn/ what other access is required?

----------

## curmudgeon

 *ewaller wrote:*   

> I ran dbus-monitor on my system and noted that the solid-hardware query does not actually generate any dbus activity -- Not what I expected :/

 

I would not have expected that either.

 *ewaller wrote:*   

> Then I started to think; What do you mean by "Battery Access"?

 

The kde battery monitor applet shows "battery not present."

 *ewaller wrote:*   

> Can your users see the contents of the /proc and /sys trees?

 

Yes.

```

$ dog /proc/acpi/battery/BAT0/info 

present:                 yes

design capacity:         6000 mAh

last full capacity:      3936 mAh

battery technology:      rechargeable

design voltage:          14800 mV

design capacity warning: 202 mAh

design capacity low:     122 mAh

cycle count:              0

capacity granularity 1:  10 mAh

capacity granularity 2:  25 mAh

model number:            Primary

serial number:            

battery type:            LION

OEM info:                Hewlett-Packard

$ ls -al /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0C0A\:00/power_supply/BAT0/

total 0

drwxr-xr-x 3 root root    0 2010-12-12 10:40:55 ./

drwxr-xr-x 3 root root    0 2010-12-12 10:40:55 ../

-rw-r--r-- 1 root root 4096 2010-12-13 19:39:58 alarm

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 charge_full

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 charge_full_design

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 charge_now

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 current_now

-r--r--r-- 1 root root 4096 2010-12-13 19:39:58 cycle_count

lrwxrwxrwx 1 root root    0 2010-12-12 10:41:12 device -> ../../../PNP0C0A:00/

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 manufacturer

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 model_name

drwxr-xr-x 2 root root    0 2010-12-13 19:39:42 power/

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 present

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 serial_number

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 status

lrwxrwxrwx 1 root root    0 2010-12-12 10:41:11 subsystem -> ../../../../../../class/power_supply/

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 technology

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 type

-rw-r--r-- 1 root root 4096 2010-12-12 10:40:55 uevent

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 voltage_min_design

-r--r--r-- 1 root root 4096 2010-12-12 10:41:12 voltage_now

```

 *ewaller wrote:*   

> Beyond seeing the state and info of the batteries in /proc/acpi/battery/BATn/ what other access is required?

 

I don't really know. Whatever kde needs to "see" the battery. I am more confused than ever if the solid-hardware query doesn't generate any dbus activity.

----------

## curmudgeon

This might be of some use:

```

$ hal-device 

Empty HAL device list.

$ strace hal-device

execve("/usr/bin/hal-device", ["hal-device"], [/* 39 vars */]) = 0

brk(0)                                  = 0x830d000

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7740000

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)

open("/etc/ld.so.cache", O_RDONLY)      = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=97793, ...}) = 0

mmap2(NULL, 97793, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7728000

close(3)                                = 0

open("/usr/lib/libhal.so.1", O_RDONLY)  = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P/\0\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=66924, ...}) = 0

mmap2(NULL, 69896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7716000

mmap2(0xb7726000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7726000

close(3)                                = 0

open("/usr/lib/libdbus-1.so.3", O_RDONLY) = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320c\0\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=239548, ...}) = 0

mmap2(NULL, 242880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb76da000

mmap2(0xb7714000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x39) = 0xb7714000

close(3)                                = 0

open("/lib/libc.so.6", O_RDONLY)        = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@m\1\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=1491228, ...}) = 0

mmap2(NULL, 1497384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb756c000

mmap2(0xb76d4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x168) = 0xb76d4000

mmap2(0xb76d7000, 10536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76d7000

close(3)                                = 0

open("/lib/libpthread.so.0", O_RDONLY)  = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220I\0\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=120940, ...}) = 0

mmap2(NULL, 102892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7552000

mprotect(0xb7567000, 4096, PROT_NONE)   = 0

mmap2(0xb7568000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15) = 0xb7568000

mmap2(0xb756a000, 4588, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb756a000

close(3)                                = 0

open("/lib/librt.so.1", O_RDONLY)       = 3

read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\31\0\0004\0\0\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=34648, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7551000

mmap2(NULL, 33392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7548000

mmap2(0xb754f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7) = 0xb754f000

close(3)                                = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7547000

set_thread_area({entry_number:-1 -> 6, base_addr:0xb75476c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0

mprotect(0xb754f000, 4096, PROT_READ)   = 0

mprotect(0xb7568000, 4096, PROT_READ)   = 0

mprotect(0xb76d4000, 8192, PROT_READ)   = 0

mprotect(0xb7714000, 4096, PROT_READ)   = 0

mprotect(0xb7726000, 4096, PROT_READ)   = 0

mprotect(0x804c000, 4096, PROT_READ)    = 0

mprotect(0xb7761000, 4096, PROT_READ)   = 0

munmap(0xb7728000, 97793)               = 0

set_tid_address(0xb7547728)             = 7000

set_robust_list(0xb7547730, 0xc)        = 0

futex(0xbfa0eb40, FUTEX_WAKE_PRIVATE, 1) = 0

futex(0xbfa0eb40, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, b75476c0) = -1 EAGAIN (Resource temporarily unavailable)

rt_sigaction(SIGRTMIN, {0xb7556340, [], SA_SIGINFO}, NULL, 8) = 0

rt_sigaction(SIGRT_1, {0xb7556860, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0

rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0

getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0

uname({sys="Linux", node="regnant", ...}) = 0

brk(0)                                  = 0x830d000

brk(0x832e000)                          = 0x832e000

socket(PF_FILE, SOCK_STREAM, 0)         = 3

connect(3, {sa_family=AF_FILE, path="/var/run/dbus/system_bus_socket"}, 33) = 0

fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)

fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0

fcntl64(3, F_GETFD)                     = 0

fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0

geteuid32()                             = 1000

rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTART}, {SIG_DFL, [], 0}, 8) = 0

poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])

write(3, "\0", 1)                       = 1

write(3, "AUTH EXTERNAL 31303030\r\n", 24) = 24

poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])

read(3, "OK 59cf1129479d53b0a407d62500000"..., 2048) = 37

poll([{fd=3, events=POLLOUT}], 1, -1)   = 1 ([{fd=3, revents=POLLOUT}])

write(3, "BEGIN\r\n", 7)                = 7

poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])

writev(3, [{"l\1\0\1\0\0\0\0\1\0\0\0n\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 128}, {"", 0}], 2) = 128

clock_gettime(CLOCK_MONOTONIC, {483, 124817734}) = 0

poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])

read(3, "l\2\1\1\n\0\0\0\1\0\0\0=\0\0\0\6\1s\0\5\0\0\0:1.17\0\0\0"..., 2048) = 260

read(3, 0x830e630, 2048)                = -1 EAGAIN (Resource temporarily unavailable)

writev(3, [{"l\1\0\1\30\0\0\0\2\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\23\0\0\0org.freedesktop.Hal\0", 24}], 2) = 168

clock_gettime(CLOCK_MONOTONIC, {483, 125861518}) = 0

poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])

read(3, "l\2\1\1\4\0\0\0\3\0\0\0=\0\0\0\6\1s\0\5\0\0\0:1.17\0\0\0"..., 2048) = 84

read(3, 0x830e630, 2048)                = -1 EAGAIN (Resource temporarily unavailable)

writev(3, [{"l\1\0\1{\0\0\0\3\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"v\0\0\0type='signal',interface='org"..., 123}], 2) = 267

clock_gettime(CLOCK_MONOTONIC, {483, 126885117}) = 0

poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])

read(3, "l\2\1\1\0\0\0\0\4\0\0\0005\0\0\0\6\1s\0\5\0\0\0:1.17\0\0\0"..., 2048) = 72

read(3, 0x830e630, 2048)                = -1 EAGAIN (Resource temporarily unavailable)

writev(3, [{"l\1\0\1\0\0\0\0\4\0\0\0\206\0\0\0\1\1o\0\34\0\0\0/org/fre"..., 152}, {"", 0}], 2) = 152

clock_gettime(CLOCK_MONOTONIC, {483, 127748149}) = 0

poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])

read(3, "l\3\1\1#\1\0\0\5\0\0\0m\0\0\0\6\1s\0\5\0\0\0:1.17\0\0\0"..., 2048) = 419

read(3, 0x830e630, 2048)                = -1 EAGAIN (Resource temporarily unavailable)

write(2, "Empty HAL device list.\n", 23Empty HAL device list.

) = 23

writev(3, [{"l\1\0\1{\0\0\0\5\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"v\0\0\0type='signal',interface='org"..., 123}], 2) = 267

clock_gettime(CLOCK_MONOTONIC, {483, 129070319}) = 0

poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])

read(3, "l\2\1\1\0\0\0\0\6\0\0\0005\0\0\0\6\1s\0\5\0\0\0:1.17\0\0\0"..., 2048) = 72

read(3, 0x830e630, 2048)                = -1 EAGAIN (Resource temporarily unavailable)

exit_group(31)                          = ?

```

----------

## curmudgeon

Here is something else (from /var/log/messages):

```

Dec 14 01:28:48 system dbus-daemon: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.11" (uid=1000 pid=2872 comm="lshal) interface="org.freedesktop.Hal.Manager" member="GetAllDevices" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=2790 comm="/usr/sbin/hald))

```

And also:

```

$ id

uid=1000(user) gid=1000(user) groups=1000(user),0(root),10(wheel),11(floppy),14(uucp),16(cron),18(audio),19(cdrom),27(video),35(games),85(usb),250(portage),440(plugdev),441(haldaemon),442(messagebus)

```

----------

## bandreabis

I installed kde4.6 which does not need hal anymore, so I unmerged hal.

And I have the same issue.. moreover 

```
solid-hardware query 'IS Battery' 

```

returns me an error.

----------

