On 6/1/07, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
On Fri, Jun 01, 2007 at 12:37:58AM -0400, Dmitry Torokhov wrote: > On Friday 01 June 2007 00:08, Matthew Garrett wrote: > > If you let users alter the kernel keymap, then you need to implement > > support for resetting the kernel keymap on exit. Otherwise it's a > > trivial DoS. > > > > You already do - do you let your users play games with force-feedback > joysticks? To load force feedback effect you need write permissions for > corresponding event device. That's much less of a problem, especially since (realistically) any force feedback-aware application will reset the values on first use. That's not the case for the keymap.
What I am trying to say - there already EVIOCSKEYCODE ioctl in the kernel. And for force feedback devices to work you need to nable writing to corresponding /dev/input/eventX thus opening possibility to alter the keymap table. I guess you coudl analyze capabilities of a device and only relax permissions for devices that have FF... Anyway, I think that we don't want ordinary users to alter hardware keymapping, it should indeed be priveleged operation done by box's administrator. Hopefully the infrastructure (hal/udev/whatever) will be able to load proper keymap at boot time so even that is not needed. Why I think using kernel remapping_in addition_ to X remapping is better: - X remapping only works in X. Even if you say that major distributions presently moved all logic in X but I don't think it is the only true way (in fact I think that some of it should run as standalone daemons; if I press power button I want my box to shut down even if I happen to be at text console. Same goes for sleep). - KEY_PROG* are assigned somewhat randomly across devices, with KEY_PROG1 matching FN-F1 on laptop multimedia key and also on one of the buttons on that remote control that manufacturers tend to supply with those "desktop replacement" laptops. Remapping them in X will not satisfy user. However remappig into actions (like KEY_EJECTCD) on kernel level solves this. From user perspective there isn't really any difference - he assigns an action to a key. - Having devices generate KEY_UNKNOWN with a nice dialog box explaining what had happened will alert users of existance of events generated by such (esp. if they are unlabeled and hit by accident). For labeled keys we may ask user to submit necessary data to one of the projects (HAL?) to add to the database of devices/models/keymaps. If we were generating KEY_PROG1 more sophisticated users would simply remap the keys and move on without telling anybody. - If using X remapping alone every user will have to repeat the task of mapping keycodes. In case when there are labels on the keyboard (but the kernel does not know what it is) that setup is likely to be identical for most users on the box. I venture to say that even with unlabeled keys the setup will be identical - first user will influence the rest. The biggest cons for KEY_UNKNOWN + scancode is that presently we do not have the code to iteract with user.
> > The standard setup in an office environment is likely to be > > multiuser. > > Huh? In my limited experience everyone in the office gets its own box. > And I am not talking about software shop. Standard is that everyone gets their own machine, but usually everyone has an account on all of them.
Which is never used (except remotely)... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
