SHMConfig is a security risk. Here is an extract of an IRC discussion regarding enabling it:
< mjg59> amitk: I really wouldn't recommend shipping anything to anyone with that set < bryce> mjg59: am I remembering correctly that SHMConfig presents a security concern? < mjg59> Yes < amitk> ogra: mjg59: Is there a better solution for keypad locking? < mjg59> Yes. Implement XInput properties. < mjg59> amitk: But if you mean with existing code, then no. There's no secure way of implementing it. < bryce> amitk: there was a bug (with a patch) on adding SHMConfig by default, but the memory access situation was determined to be a security issue, so the patch was not accepted < kees> amitk: err... I thought the synaptic controls had already been added to the mouse controls (by mjg59) < mjg59> kees: No, only a subset of them < amitk> mjg59: It has to be existing code. We can't devote a whole lot of time to this one. < mjg59> amitk: Then it's not possible < mjg59> amitk: SHMconfig generates a shared memory segment that's world writable. Any user can alter the coordinate mapping on the pad in order to trigger mouse presses at arbitrary points on the screen < mjg59> amitk: And if you enable this for anyone, I swear that I will write an exploit for it :) < mjg59> Oh, also it'll utterly fail in the fast user switching case < amitk> mjg59: point taken. I'll enable it with the warning 'mjg59 is out to get you' :) < mjg59> amitk: Seriously. It's not in the slightest bit acceptable for this to go in anything that ships to anyone. < jdong> mjg59: is there a better method of implementing a touchpad-keyboard interlock that doesn't come with the implications of < bryce> amitk: there was also a follow on patch to the bug I mentioned earlier, which the submitter claimed did not have the security issue, but I don't think that was reviewed. < mjg59> jdong: They don't currently exist. It's analagous to the xrandr properties < amitk> bryce: do you have a bug number? < mjg59> jdong: Essentially, allow input drivers to provide properties < bryce> amitk: one sec < mjg59> Then they can be runtime configured within the confines of the existing X security model < bryce> amitk: 155937
Enabling touchpad locking through Fn+Fxx keys
- Assume keysequence to be Fn+F12
- Edit /etc/X11/xorg.conf and add the following option to the synaptics driver section
Option "SHMConfig" "1"
- Restart X
- Check that the following command works
- Use the following command to disable the touchpad
- ...and to re-enable it, use
- Now to hookup the Fn+F12 keycode to this action. It will require a script to keep track of the current state of the touchpad.
- see /etc/acpi/events/asus-a6u-touchpad and /etc/acpi/asus-touchpad.sh for a script that enables/disables the touchpad for laptops where the built-in hotkey generates a "6b" ACPI event (tested with Toshiba L40-14N on Gutsy)