Messages in this thread | | | Date | Sat, 21 Jul 2012 13:08:55 -0300 | From | Henrique de Moraes Holschuh <> | Subject | Re: sysfs permissions on dynamic attributes (led delay_on and delay_off) |
| |
On Sat, 21 Jul 2012, Colin Cross wrote: > The delay_on and delay_off files could easily override the values from > the trigger. > > Sending a KOBJ_CHANGE uevent is not a great solution, it's still > horribly racy in userspace. This script would never work reliably: > echo timer > trigger > echo 1000 > delay_on > echo 1000 > delay_off > echo 255 > brightness
Yes, and the proper fix is to instead use a fully async userspace based on uevent callbacks. Nasty as all hell. Or the quick fix, which is to wait for the system to settle after every sysfs operation that could create new sysfs nodes.
You could make sure that (1) no sysfs operation will return control to userspace until it is complete, so you'd have all new sysfs nodes available at the time the first echo returns [I believe it already works like that], and (2) either enhance sysfs to create nodes with the desired ownership and permissions -- which requires feeding policy rules to it beforehand at the very least; or do it as whichever priviledged user/group has default write access to sysfs nodes.
This is a general problem. I have no idea whether Richard will allow the triggers hack to work around it or not, and I really don't care. But the bad sideffects of the hack that he pointed out are all very true, and far reaching in time.
-- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
| |