Wine inconsistent behavior

Bug #565233 reported by Eduardo Cintas
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
wine1.2 (Ubuntu)
Triaged
Undecided
Scott Ritchie

Bug Description

Binary package hint: wine

If you click an exe from Dolphin a wine task load and suddenly closes. But if you execute "wine foo.exe" wine load the program successfully. Doing some Goggling I have discovered that if you set the executable flag to the exe file you can click it and load correctly. It's not intuitive you can expect that clicking "foo.exe" and executing "wine foo.exe" do the same thing. Also, if there is a need to set executable flag we need some feedback. Wine is closing silently now. In another aspect executable flag can't be set on CD's/DVD's so I think that not a good Idea. At practical aspect a no technical user seem that wine have working well on karmic and now it's broken and the distro is involutionating.

Sry for my bad English
Best Regards, Eduardo Cintas.

See also bug #561479, bug #552323

description: updated
Jack Leigh (leighman)
description: updated
Revision history for this message
Scott Ritchie (scottritchie) wrote :

I am quite aware of how annoying it is. I have a proper replacement for the whole dialog planned, my current goal is to backport it along with Wine 1.2 when its finalized.

In the meantime if you use the Wine Team PPA it will disable cautious launcher entirely.

affects: wine (Ubuntu) → wine1.2 (Ubuntu)
Changed in wine1.2 (Ubuntu):
assignee: nobody → Scott Ritchie (scottritchie)
status: New → Triaged
Revision history for this message
Corrado Mella (c-mella) wrote :

Sorry, but this is NOT a duplicate of #561479.

This is a stupid bug caused by the "cautious-launcher" script author, that is using Zenity to create a GUI error window to inform the user of the execute-bit problem.

On Kubuntu, Zenity is NOT installed by default, so the cautious-launcher script falls back to a console message (echo blah blah) that is obviously totally invisible when the windows .EXE is started from the GUI clicking on it.

An "echo" to a command line shell is NOT an acceptable substitute for a GUI window message!!!

This is pretty basic stuff, I'm stunned nobody has triaged the cautious-launcher script before using it in Wine.

Who wrote this script???

Revision history for this message
VestniK (vestnik) wrote :

 Since check for the executable bit is performed not by wine itself intermediate script should be rewritten in better way. Message should be shown to the users of desktop environment other than GNOME as well.

I've extended the cautious-launcher script with additional checks which will deliver message to the user in most of the cases.

Revision history for this message
Jonathan Marsden (jmarsden) wrote :

The duplicate status of this bug seems incorrect.

#144335 is about nautilus executing too many things.

In contrast, #565233 is about cautious-launcher (a) not displaying its messages in some environments, and (b) being more restrictive than the relevant policy requires.

While the supplied patch by VestniK solves the "not displaying its messages" piece of this issue, nothing has yet addressed the "is more restrictive that required" part, as far as I can see.

The specification at https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission%20Bit%20Required is:

  Applications, including desktops and shells, must not run executable code from files when they are both:
    lacking the executable bit
    located in a user's home directory or temporary directory.

cautious launcher checks whether the file is under /usr/ or /opt/ instead of checking whether it is in the users home dir or in a temporary file area. Is there a good reason for this?

In particular, allowing files mounted under /media/ would handle the "file is on a CDROM" case much of the time.
Better still would be a check for whether the file is under the users home dir ($HOME) or in a temporary directory (under /tmp or /var/tmp ).

I can code that and provide a debdiff -- would such a change be accepted and useful?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.