From: Helge Hafting <helge.hafting@aitel.hist.no>
To: "Daniël Mantione" <daniel.mantione@freepascal.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Keyboard programming needs root
Date: Tue, 24 Jul 2007 16:05:33 +0200 [thread overview]
Message-ID: <46A6072D.7020807@aitel.hist.no> (raw)
In-Reply-To: <Pine.LNX.4.61.0707191748340.10291@idefix.wisa.be>
Daniël Mantione wrote:
> Op Thu, 19 Jul 2007, schreef Dmitry Torokhov:
>
>
>> Hi Daniel,
>>
>> On 7/14/07, Daniel Mantione <daniel.mantione@freepascal.org> wrote:
>>
>>> Hello,
>>>
>>> A while back a patch was merged to make that only root can program the
>>> keyboard:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968
>>>
>>> Is this patch discussable? I think this patch isn't proper because of the
>>> following reasons:
>>>
>>> * Users can play games in many ways. They can configure the terminal
>>> settings, (remove the automatic line feed, disable the echo etc). They
>>> can
>>> load console fonts. They can still put the keyboard in raw mode, etc.
>>>
>> Keyboard raw mode or disabling line echo may be annoying but you
>> really don't want someone leaving box after binding "rm -rf /" to a
>> backspace key...
>>
>
> As I said, the proper solution to this problem is to restore the keyboard
> in a known state after logout. There is no need for the kernel to change
> behaviour. Many operating systems allow changing keyboard layout and can
> because there is no need for it to be insecure.
>
> However, I can agree that in some cases, as per system policy,
> administrators mays want to prevent this.
>
>
>>> * All of these games can be prevented by making mingetty (or whatever
>>> getty is used) or PAM can put the console into a known state after
>>> logout.
>>> * All of these games are annoyances, system security is not
>>> compromised.
>>> * I do not see a problem with for example a French user doing a "loadkeys
>>> fr" if that allows hims to use the computer easier.
>>>
>>> Worst issue for me though, is that KDSBENT is needed to be able to catch
>>> keys like shift+tab, alt+fx, escape without delay. My application
>>> suddenly
>>> needs root permissions to work properly.
>>>
>> Yes, if your application mucks with the console it has to be trusted...
>>
>
> That is not really constructive: I don't want to muck with the console, I
> a working keyboard. Linux just just requires you to muck with the console if
> you want a working keyboard. Many applications, Midnight Commander to name
> one, work around Linux console limitations (try ctrl+arrows,
> works as expected despite not supported by Linux).
>
> Now if you force applications to work around limitations, you have a
> certain responsibility not to break them.
>
>
>>> The alternative, semi raw mode,
>>> has the disadvantage that you need to implement your own keymaps (like
>>> X).
>>> In short, this change breaks applications.
>>>
>>>
>> You may also try reading data directly from evdev devices... They are
>> normally privileged as well but usually user logged on console is
>> given access to them.
>>
>
> evdev has the same problem as medium/full raw mode: You need your own
> keyboard maps. This makes this solution not very practical.
>
> To make this discussion productive, I want to work towards a solution. I
> don't mind how I can make the keyboard work as it should, I just want it
> work. Think of the needs of a user interface, you walk through controls
> using tab and shift+tab, put common commands under the function keys and
> shift/control/alt combinations. Cursor control in an editor is done with
> the navigation pad on your keyboard: arrows, home/end/pgup/pgdown, plus
> shift/control/alt combinations with them.
>
> That is all, nothing fancy. Could the kernel support a way to do this?
>
The normal way is to set permissions on the device in
question - give either root only or the logged-in user
write access as needed.
It seems to me that "loadkeys" uses /dev/tty / /dev/tty0
So set permissions on that as needed.
Helge Hafting
next prev parent reply other threads:[~2007-07-24 14:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-14 6:32 Keyboard programming needs root Daniel Mantione
2007-07-19 15:17 ` Dmitry Torokhov
2007-07-19 16:27 ` Daniël Mantione
2007-07-24 14:05 ` Helge Hafting [this message]
2007-07-24 14:39 ` Daniël Mantione
[not found] <8GK58-g5-5@gated-at.bofh.it>
[not found] ` <8IFXs-1xs-21@gated-at.bofh.it>
[not found] ` <8IHcN-3pZ-5@gated-at.bofh.it>
2007-07-19 17:52 ` Bodo Eggert
2007-07-21 9:03 ` Daniël Mantione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46A6072D.7020807@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=akpm@linux-foundation.org \
--cc=daniel.mantione@freepascal.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox