Bugzilla – Bug 115003
use libpmud instead of accessing /dev/pmu directly?
Last modified: 2006-09-28 13:26:24 UTC
I receive an error about permissions on /dev/pmu upon logging in to Gnome. I will attach a screenshot.
Created attachment 48619 [details] Screenshot of error
Created attachment 48621 [details] y2log, if useful
Created attachment 48623 [details] cropped version
What permissions do you have on /dev/pmu? GNOME is attempting to use the device to notice when the brightness keys are hit. Perhaps resmgr can give perms for the desktop user here?
crw-rw---- 1 root root 10, 154 2005-08-19 19:42 /dev/pmu
I've never heard of this device before. I cannot judge whether it's safe to grant users access to /dev/pmu, someone would need to check the kernel code. Things in /usr/src/linux/include/linux/pmu.h sound like it's a quite low level device and users should better not get access: 20 #define PMU_WRITE_NVRAM 0x33 /* write non-volatile RAM */ 22 #define PMU_SET_RTC 0x30 /* set real-time clock */ 32 #define PMU_SHUTDOWN 0x7e /* turn power off */ 37 #define PMU_RESET 0xd0 /* reset CPU */ Powersaving features should be handled by powersaved. For key like events the kernel driver should provide an event interface. Access to that one could be granted then.
it is safe to use 666 or whatever.
on the other hand, link against libpmud and ask the running pbbuttonsd. it likely has code to notify userland.
still present in beta4
Well, AFAICS there are now three possible ways to solve the problem. Someone needs to decide which one to use. To me the libpmud way sounds like the best. [ ] use libpmud -> gnome-maintainers [ ] make device 666 or 660 root:video -> udev [ ] use resmgr -> /dev/pmu needs to be in hal, then -> hal-resmgr
Well, my opinion is that [ ] make device 666 or 660 root:video -> udev is best (at least for SL 10.0) because it requires no code changes and 1 and 3 do.
Ok, lets have it 660 root:video then. So at least random daemons don't have access.
660 is the default. I've added: KERNEL=="pmu", GROUP="video" Will someone take over the bug for the remaining issues? Otherwise I will close it.
fig.suse.de has rc1 installed. how would the resmgr fix look like?
/proc/pmu is already read by HAL. Maybe there is not much missing to make it work using HAL. LCDBrightness Methods made it into the latest HAL version, so this may be the rigth solution for this?
the device needs to be known to hald, see output of lshal. Then you can add rules that match for the device to /usr/share/hal/fdi/policy/10osvendor/80-resmgr.fdi, just like it's done for e.g. joysticks. resmgr will then install ACLs on the file when you log in (and give you a fd if you use libresmgr to open the device).
lshal doesnt know about /dev/pmu
@olaf: Could you do this?: - stop hal (with 'rchal stop') - hald --verbose=yes --daemon=no --retain-privileges > /tmp/hal_log 2>&1 - wait 20 seconds - stop hal and attach the file to the bug could you also attach a 'ls -lha *' of the related dir in /sys and maybe a archive with copy of the dir with all files?
Created attachment 53610 [details] bug115003.tar.bz2
@kay: any ideas how to add /dev/pmu to hal? I have currently no plan how and as which kind of device we can add it. Please take a look at this.
@danny: I have absolutely no idea about that architecture. Someone else should look at this.
erm, imagine you want to provide info for /dev/rtc or other misc devices.
What are you talking about?
yes, how do you provide /sys/class/misc/*? this is what we are talking about.
You mean HAL? HAL is not involved in misc devices.
ok, then its not fixable.