Bug 172425 - kernel - consistent "KDGKBSENT" messages on login
Summary: kernel - consistent "KDGKBSENT" messages on login
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kbd   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact:
URL:
Whiteboard:
Keywords:
: 174677 174850 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-04 09:49 UTC by Michal Jaegermann
Modified: 2008-02-12 15:19 UTC (History)
10 users (show)

Fixed In Version: 1.12-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 22:12:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Michal Jaegermann 2005-11-04 09:49:35 UTC
Description of problem:

Every time when I am trying to log on a text console on a non-root account,
and when running 2.6.14-1.1639_FC5, I see the following:

KDGKBSENT: Operation not permitted
KDGKBSENT failed at index 0: 

This does not happen when I am logging as root or if I am running my
previous installed kernel, i.e. 2.6.14-1.1635_FC5 or earlier.  AFICT these
error messages do not register in any logs or in dmesg buffer but only on
a console.

I do not see, so far, any harmful consequences beyond annoyance but in that
form this is something clearly new.

Version-Release number of selected component (if applicable):
kernel-2.6.14-1.1639_FC5

How reproducible:
always

Comment 1 Michal Jaegermann 2005-11-06 01:01:14 UTC
Rechecked with 2.6.14-1.1644_FC5 and no changes.

Comment 2 John Ellson 2005-11-07 19:15:31 UTC
me too on x86_64 with kernel-2.6.14-1.1651_FC5

Comment 3 Michal Jaegermann 2005-11-13 20:59:37 UTC
With kernel kernel-2.6.14-1.1663_FC5 I see now probably more informative
(although this is probably a result of a new version of 'kbd' package)

Keymap 0: Permission denied
Keymap 1: Permission denied
Keymap 2: Permission denied
KDSKBENT: Operation not permitted
loadkeys: could not deallocate keymap 3

and these indeed can be repeated by a 'loakeys' run from a non-root account.
The catch is that nowhere in my startup files, AFAIK, I am trying to run
'loadkeys'.  So this may be a user-space issue caused by limiting some
operations allowed by a kernel but who is really the culprit? 'login' itself?
"KDSKBENT" message does not seem to be coming from 'loadkeys' although the
other most likely are.

Comment 4 Dennis Jacobfeuerborn 2005-11-22 14:21:27 UTC
I see this too with kernel-devel-2.6.14-1.1682_FC5 and kbd-1.12-11.

Comment 5 nyinge 2005-11-22 19:44:21 UTC
I also confirmed this error output on 2.6.14-1.1696_FC5, when I log in as
non-root user.

Comment 6 Dave Jones 2005-12-01 04:43:47 UTC
I added a debug printk that prints the app name when that ioctl fails due to
EPERM.  It's definitly loadkeys.  It does it 4 times for each login on my testbox.

I've no idea what's actually calling /bin/loadkeys.
Reassigning to kbd maintainer, who hopefully has some clues.

Mitr, that ioctl is no longer valid to be called as a regular user.


Comment 7 Dennis Jacobfeuerborn 2005-12-01 20:05:55 UTC
/bin/loadkeys is used by /bin/unicode_start like this:

======
...
# Change the keyboard mapping in such a way that the non-ASCII keys
# produce UTF-8 encoded multibyte sequences, instead of single bytes
# >= 0x80 in a legacy 8-bit encoding.

dumpkeys | loadkeys --unicode
...
======

/bin/unicode_start is called by /etc/profile.d/lang.(c)sh like this:

======
...
    if [ -n "$LANG" ]; then
      case $LANG in
        *.utf8*|*.UTF-8*)
        if [ "$TERM" = "linux" -a "`/sbin/consoletype`" = "vt" ]; then
                [ -x /bin/unicode_start ] && /sbin/consoletype fg &&
unicode_start $SYSFONT $SYSFONTACM
        fi
        ;;
      esac
    fi
...
======


Comment 8 Michal Jaegermann 2005-12-01 21:34:52 UTC
/bin/unicode_start is a shell script.  Maybe it is enough to do there

[ "$(id -u)" = 0 ] && dumpkeys | loadkeys --unicode

to guard that line?  It looks that this solves the problem.


Comment 9 Miloslav Trmač 2005-12-01 22:05:37 UTC
*** Bug 174677 has been marked as a duplicate of this bug. ***

Comment 10 Miloslav Trmač 2005-12-01 22:12:06 UTC
I have simply removed the dumpkeys | loadkeys line in kbd-1.12-12; rc.sysinit
uses (loadkeys -u) anyway.

Thanks for your report.

Comment 11 Miloslav Trmač 2005-12-02 19:39:57 UTC
*** Bug 174850 has been marked as a duplicate of this bug. ***

Comment 12 Aristeu Rozanski 2007-08-21 18:54:22 UTC
This began to happen because users being able to modify the local console keymap
is considered a security problem. So the kernel was modified[1] to stop allowing
users from doing it, thus the messages. see BZ#172357

[1]
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968



Note You need to log in before you can comment on or make changes to this bug.