WARNING

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

• https://bugs.edge.launchpad.net/ubuntu/+bug/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

  • synclient -l

• Use the following command to disable the touchpad

  • synclient TouchpadOff=1

• ...and to re-enable it, use

  • synclient TouchpadOff=0

• 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)