public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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