configuration of synaptics touchpads should be possible by default, and gsynaptics should be installed by default on laptops

What do you want to configure which isn't now configurable under:

System menu -> Preferences -> Mouse -> Touchpad (notebook tab)

There are settings for tap to click, vertical and horizontal scrolling.

circular scrolling, double-tap to click, the ability to adjust the speed and sensitivity of each scrolling method, general sensitivity, etc. If these were wound up into the mouse -> touchpad dialog that would be fine too.

It would also be great to have the ability to switch the touch pad on and off, and even better to detect when a mouse is plugged in and automatically turn the touch pad off. I can do that now using a script that runs gsynaptics - r and is called from the mice section in "System->Preferences->Removable Drives and Media" (a really obvious place to look for that, right?) - when I updated to Gutsy I lost SHMConfig and the ability to turn off the touch-pad even manually. Given the choice between compiz and this I have to vote for this.

What information is required to remove the 'incomplete' status? The sum of user-available knowledge is already in this report.

We are not going to use SHMConfig, instead the driver will be modified so that the setting is not needed anymore.

In current hardy alpha 4 is this still not resolved. You have to edit xorg.conf by hand, to have SHMConfig enabled.

I confirm this bug, making it valid again, hope having it resolved for Hardy.

I think a desire to disable tap-clicking is pretty common. In stable Ubuntu it is easy to disable tap-clicking via a checkbox with a default install. In Hardy A5 I have to mess around with xorg.conf. This seems like a pretty serious functionality regression to me.

Let's try.

So here it comes:

I made a patch, which enables SHMConfig by default.

Although this comes with a drawback: this option works in the way of allocating a shared memory for the configuration options. But this memory must have permissions set to 777, otherwise the logged in (usually non-root) user won't be able to change it's settings. So this way any local user logged in to X is able to change the settings.
I can't consider this as a vulnerability.

Please apply my patch, if possible.

No, as I said it will not be applied, since it's a security risk and not needed anyway. Gsynaptics should be able to work without setting that option, because our driver has been patched to support that.

May I ask how can it be configured else dynamically from userspace? Even the supplied synclient.c uses the shared memory method:

    /* Connect to the shared memory area */
    if ((shmid = shmget(SHM_SYNAPTICS, sizeof(SynapticsSHM), 0)) == -1) {
        if ((shmid = shmget(SHM_SYNAPTICS, 0, 0)) == -1) {
            fprintf(stderr, "Can't access shared memory area. SHMConfig disabled?\n");
            exit(1);
        } else {
            fprintf(stderr, "Incorrect size of shared memory area. Incompatible driver version?\n");
            exit(1);
        }
    }

It's not working for me, either, and I don't see anything about such a change in the changelog.

Because I couldn't find any other interface in the source code, I enabled SHMConfig by default again.

Although permissions (for the shared memory) is set to 0770.

I also introduced a new option, "SHMGroup", set by default to "admin".
When SHMConfig is on, the shared memory area will belong to the GID of this group. If the group does not exists, it falls back to 0 (root).

This way any user in the SHMGroup is able to configure the touchpad. Also the first user in a default install, without modifying xorg.conf.

This can no longer be considered as a security risk, because all members of the group "admin" (default SHMGroup value) are able to use sudo (with their own passwords) by default, so they could do "nasty things" either way.

This change is documented. I also updated synclient and syndaemon to handle a permission denied on the shared memory.

Patch attached.

also patched the manpage to reflect the changes

Sigh, please understand that this won't happen..

To quote Matthew Garrett who added the interface; "SHMConfig can't be enabled by default. Ever."

I am curious about how a contributor can make a change like making "SHMConfig" not default and be allowed to cause a regression like this. If there is supposedly a safe way to add this functionality back why wasn't code to do so included with the patch that removed it in the first place? Is making changes without fixing the fallout acceptable if the change is done in the name of security? That probably makes sense but I still feel like the contributor should make fixing resulting regressions a priority after the fact. Gabor seems to be making an effort but apparently he doesn't have the right info, can we get the person who does (maybe the person that caused this and/or added the replacement interface) to help him out at least with some specific advice about a strategy for making use of the replacement interface?

Thanks for working on this guys.

@Timo Aaltonen: Please review my post and patch again. The patch changes how SHMConfig works! The problem with SHMConfig "on" was, that it created a shared memory with permission bits set to 0777. I agree with you that this is not acceptable, because any (unpriviligized) local user could have written to the memory area of a root process, and Illegal values may cause undefined behavior.
My patch resolves this by assigning the memory to a specific, privileged group, and setting the permission bits to 0770. Default SHMConfig "on" and default SHMGroup "admin" can not cause any trouble this way, because even when the data structure is located in a shared memory area, only the root user and users in the admin group have access to it. And users in the admin group have already root acces (via sudo) by default, so they could become root, and modify the particular memory area either way.
Please point it out if I miss something, but I don't see a security issue anymore.

It would be also possible to let SHMConfig as it is (and off by default), and introduce my patch as the SHMSecureConfig option, which could be on by default. Shall I rewrite my patch in this way?

Also I would be grateful for any information about the control interface you mentioned earlier. Is this the
static int ControlProc(LocalDevicePtr local, xDeviceCtl * control)
in synaptics.c?

Here is an another solution, that does not enable SHMConfig by default!

It is the same idea, except it leaves SHMConfig untouched. But introduces the option SHMSecureConfig, that is enabled by default, and makes the configuration available via shared memory although only for the group specified in option SHMGroup (default is "admin"). Permission bits for the shared memory are set to 0770! Please point out if this could cause security issues in any way: even the configuration remains 100% compatible with older ones.

changed status to new, because the bug is no longer about enabling SHMConfig by default

mjg59 comments:

"Yeah, that's an improvement. However, it still means that remote X clients can influence the input stream in a way they currently can't
Also, that any user with admin privileges can screw everyone else. Though given sudoers, that's a given.
 I dislike tying desktop functionality to an admin group, though. It encourages people to make normal users admins."

Timo adds that Synaptics is deprecated upstream. I'm afraid we need to just sit tight and wait for Xinput to become available in Ubuntu. But I will keep this bug open until that time - this is a common issue and there is some good analysis/patching in this bug, and while we won't be carrying this patch in the general distro due to security issues, the patch may be of interest to other Ubuntu users who can deal with or accept the security implications themselves in some fashion.

Correct me if I am wrong but if we don't fix gsynaptics settings not sticking (fixed upstream, but not in Hardy, Bug #70525 ), I think solving this bug won't be very useful. Am I correct ?

I can confirm that.

The synaptics driver now allows changing settings at runtime (on intrepid). Install 'xinput' and see the manpage. Closing as fixed.

Cool... now all we need is for synclient to be rewritten to use xinput... hopefully without losing the ability to do 'synclient -m <time>'. (Synclient itself is part of the synaptics driver package.)
Once synclient is rewritten, gsynaptics will be able to simply use synclient.

Anything new here? I installed 9.04 on my Acer Aspire One and have exactly this problem.

You can now go into mouse preferences and disable tapping...

On Fri, Apr 3, 2009 at 9:57 AM, Olaf <email address hidden> wrote:

> Anything new here? I installed 9.04 on my Acer Aspire One and have
> exactly this problem.
>
> --
> configuration of synaptics touchpads should be possible by default, and
> gsynaptics should be installed by default on laptops
> https://bugs.launchpad.net/bugs/155937
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

No, I cannot go into preferences because I get this "enable SHMmem" error. :-(
Funny that this bug still exists in 9.04

On Sat, 2009-04-04 at 07:49 +0000, Olaf wrote:
> No, I cannot go into preferences because I get this "enable SHMmem" error. :-(
> Funny that this bug still exists in 9.04

Try installing xserver-xorg-input-synaptics 1.1.0 from my main PPA.

--
William Grant

Thank you, William, now it works!

GSynaptics should not be installed by default. The Gnome Mouse settings should be able to control everything that GSynaptics does. Why have two independent apps for the same thing?

It looks like this issue has been addressed, so I am closing this bug.