[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100416053305.GC1078@core.coreip.homeip.net>
Date: Thu, 15 Apr 2010 22:33:05 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: Henrique de Moraes Holschuh <hmh@....eng.br>,
Linux Input <linux-input@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [RFC] Input: implement sysrq as an input handler
On Sun, Apr 04, 2010 at 03:27:34PM +0200, Pavel Machek wrote:
> 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.
Can I change Alt? Just saying... ;)
Anyway, yes, it was hardcodced in 2.4. It also was only working on AT
keyboards, and now we support much wider range.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists