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

Bug #155937 reported by Xipietotec
40
Affects Status Importance Assigned to Milestone
gsynaptics (Ubuntu)
Fix Released
Wishlist
Unassigned
Declined for Hardy by Bryce Harrington
xserver-xorg-input-synaptics (Ubuntu)
Fix Released
Wishlist
Unassigned
Declined for Hardy by Bryce Harrington

Bug Description

Binary package hint: xorg

I've seen this bug elsewhere #120104 but it was marked invalid without comment. Is there any reason why enabling SHMConfig and gsynaptics by default would have any problems with sane defaults? If we can have compiz enabled by default, with bulletproof X, for supported hardware, why not touchpad configuration? I've seen this complaint (lack of touchpad configuration by default) in several mainstream industry mags about "dekstop readiness" including the most recent one by Walt Mossberg. This should not be something terribly difficult to implement.

Comments?

Revision history for this message
Peter Clifton (pcjc2) wrote :

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.

Changed in xorg:
status: New → Incomplete
Revision history for this message
Xipietotec (nahuatl) wrote :

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.

Revision history for this message
dkohen (dkohen) wrote :

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.

Revision history for this message
Carl van Tonder (carlvantonder) wrote :

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

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

Changed in xorg:
status: Incomplete → Won't Fix
Revision history for this message
sibidiba (sibidiba) wrote :

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

Revision history for this message
sibidiba (sibidiba) wrote :

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

Changed in xorg:
status: Won't Fix → Confirmed
Revision history for this message
Josh Aas (joshmoz) wrote :

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.

Revision history for this message
sibidiba (sibidiba) wrote :

Let's try.

Changed in xserver-xorg-input-synaptics:
assignee: nobody → gab++
status: Confirmed → In Progress
Revision history for this message
sibidiba (sibidiba) wrote :

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.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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.

Changed in xserver-xorg-input-synaptics:
assignee: gab++ → nobody
status: In Progress → Won't Fix
Revision history for this message
sibidiba (sibidiba) wrote :

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);
        }
    }

Revision history for this message
Alex Wauck (awauck) wrote :

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

Revision history for this message
sibidiba (sibidiba) wrote :

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.

Changed in xserver-xorg-input-synaptics:
assignee: nobody → gab++
status: Won't Fix → New
Revision history for this message
sibidiba (sibidiba) wrote :

also patched the manpage to reflect the changes

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

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

Changed in xserver-xorg-input-synaptics:
status: New → Won't Fix
Revision history for this message
Josh Aas (joshmoz) wrote :

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.

Revision history for this message
sibidiba (sibidiba) wrote :

@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?

Revision history for this message
sibidiba (sibidiba) wrote :

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.

Revision history for this message
sibidiba (sibidiba) wrote :

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

Changed in xserver-xorg-input-synaptics:
status: Won't Fix → New
Revision history for this message
Bryce Harrington (bryce) wrote :

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.

Changed in xserver-xorg-input-synaptics:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

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 ?

Revision history for this message
sibidiba (sibidiba) wrote :

I can confirm that.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

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

Changed in xserver-xorg-input-synaptics:
assignee: gab++ → nobody
status: Confirmed → Fix Released
Revision history for this message
Dana Goyette (danagoyette) wrote :

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.

Daniel T Chen (crimsun)
Changed in gsynaptics:
importance: Undecided → Wishlist
Revision history for this message
Olaf (oz-tuxfriends) wrote :

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

Revision history for this message
Matt (mmmurf) wrote : Re: [Bug 155937] Re: configuration of synaptics touchpads should be possible by default, and gsynaptics should be installed by default on laptops

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.
>

Revision history for this message
Olaf (oz-tuxfriends) wrote :

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

Revision history for this message
William Grant (wgrant) wrote : Re: [Bug 155937] Re: configuration of synaptics touchpads should be possible by default, and gsynaptics should be installed by default on laptops

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

Revision history for this message
Olaf (oz-tuxfriends) wrote :

Thank you, William, now it works!

Revision history for this message
Endolith (endolith) wrote :

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?

Revision history for this message
Alex Wauck (awauck) wrote :

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

Changed in gsynaptics (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers