Hi! > > If userspace disables sysrq during normal operation, that makes it > > useless. > > > > If normal user could do that, that's a security problem. > > > > Yes, and...? This patch does not change the way one enables, disables, > intercepts, etc. SysRq and SAK compared to how it was handled when SysRq > was part of keyboard _input handler_. The only thisng this patch does is > moving the code into a _separate_ input handler. Yep, that was just a note. > > > The problem is that device does not know what SysRq and especially SAK are. > > > User can reassign key codes and key symbols easily. > > > > That was not case in original implementation; it had hardcoded keymap. > > The earth was also flat back then and the only keyboard was AT one. SAK > was always part of keymap so could be reassinged at any time. Well, there are two SAKs. One SAK -- in keymap, is remappable and always was. Second, sysrq-saK -- is (was?) hardcoded and not affected by keymap. Please don't change that. > > > I don't think we had any issues like this since 2.5 so I would not worry > > > about userspace too much. If anything we just need to review what stuff > > > we run as root (we do that anyway, right?). > > > > Hehe. If X can break sysrq, that's both X and sysrq problem. > > Root can disable Sysrq... News at 11. Root *does* disable sysrq is indeed news ... and problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
