Re: [PATCH 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.

[Rusty Russell <rusty@rustcorp.com.au>]

madcatxster@devoid-pointer.net writes:
> On Thu Apr 24 2014 05:25:24 GMT+0200 (CEST), Rusty Russell wrote:
>> simon@mungewell.org writes:
>> >> simon@mungewell.org writes:
>> >>> Yep I'm OK with that, however what it the recommended way to make sure
>> >>> that the end user is able to send changes to this /sys portal? I asked
>> >>> the
>> >>> same question before regarding the led class /sys interface, but never
>> >>> got
>> >>> any suggestions.
>> >>>
>> >>> Signed-off-by: Simon Wood <simon@mungewell.org>
>> >>
>> >> If you need that, we'll need to make an exception.  That's one purpose
>> >> of spamming everyone with these changs...
>> >
>> >
>> > What's the right way of doing it?... I don't need to be 'special'. ;-)
>> >
>> > The '/sys/.../range' control allows the user to limit the rotation of the
>> > gaming wheel from a maximum of 900' down to match the 'car' they
>> > sim-driving. Probably not many people use it, but it probably should be
>> > assigned properly.
>> >
>> > With gaming controllers the /dev/input/event* seem to get set
>> > appropriately, but I'm not sure how this happens.
>> >
>> > The same /should/ also happen for all the LED class controls, I don't want
>> > to have to 'sudo' just to set a LED on/off. This is currently a problem
>> > for (at least) hid-lg, hid-sony and hid-steelseries.
>> > Simon
>> 
>> I think this is a udev duty.  Someone needs to chmod/chown/chgrp the
>> files if you want to allow a particular group/user access (I just
>> checked, that works fot sysfs files).
>> 
>> I have no idea about HID, so I don't know how you'd figure out who that
>> user/group is...
>> 
>> Cheers,
>> Rusty.
>>
>
> I'll be OK with udev rules taking care of this instead of the kernel. When are these changes supposed to land in mainline?

Next merge window...

Cheers,
Rusty.