Hi! On Fri 2018-06-15 20:36:28, Henrique de Moraes Holschuh wrote: > On Fri, 15 Jun 2018, Pali Rohár wrote: > > This means that kernel should not export any led class device. Or when > > exported, then "set" operation should always fail. > > "not export" is right. > > > > 2. Otherwise implement it in-kernel, so that userspace cannot unmute > > > when the human has activated the "mute" switch, and the LED cannot be > > > controlled by userspace to lie (report mute when it is not mute). > > > > This looks like a good candidate to use led "trigger" interface. Create > > a mute trigger and attach it to that led device. > > Maybe, as long as done in-kernel and not possible to mess with from > userspace. Question is if we want flexibility or security. If we want security, going through LED subsystem makes no sense, just control the LED as hardware would, or let hardware do it. For full flexibility, just export the LED and use normal mechanisms we have (such as triggers). root should be allowed to configure the LEDs, and he can change the kernel, too, so... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
