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
Rechecked with 2.6.14-1.1644_FC5 and no changes.
me too on x86_64 with kernel-2.6.14-1.1651_FC5
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.
I see this too with kernel-devel-2.6.14-1.1682_FC5 and kbd-1.12-11.
I also confirmed this error output on 2.6.14-1.1696_FC5, when I log in as non-root user.
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.
/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 ... ======
/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.
*** Bug 174677 has been marked as a duplicate of this bug. ***
I have simply removed the dumpkeys | loadkeys line in kbd-1.12-12; rc.sysinit uses (loadkeys -u) anyway. Thanks for your report.
*** Bug 174850 has been marked as a duplicate of this bug. ***
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