Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

[Peter Dolding]

On 6/26/15, Vincent Povirk <madewokherd at gmail.com> wrote:
>> By adding a exe.mainfest with wine data or exe.winemainfest file marks
>> the
>> application as clearly to be opened by wine.
>
> FWIW Mono currently uses .exe.config files.
http://stackoverflow.com/questions/2916023/app-config-vs-appname-exe-config
.exe,config is part of a general .net application.    .config is not
for application compatibility like exe.manifest is.

Finding a .config file does not tell you if the .net applications is
for Linux or for .net inside wine or what version .net.
>
>> Also just using MINE type does not tell you want WINEPREFIX the
>> application owns to.
>
> In any normal case, an exe file that "belongs to" a wineprefix will be
> located in its C drive. That shouldn't be hard to find by traversing
> parent directories.
>
That is presuming no symbolic or hardlinks in the process.  Traversing
directories is not dependable.   So this part of the process you most
likely want to pop up a Window/text on console asking user if
tranvering is correct then record the users reply.

Normal case is presuming user does not alter install directory of
applications.   Basically this is users have to do it your way or
else.   Instead of making the system as tolerant as possible.   Like
under windows installing on D: instead of C: is acceptable users
install application on z: somewhere should also be acceptable    So
breaking solve by Traversing.  So Traversing covers only a limited
number of cases and is not dependable so should have user interaction
if used.   Yes I don't want to have to ask a user every time they run
a executable if I have the right wineprefix.

>> Yes setting up binfmt-misc requires root.  But binfmt-misc is where non
>> native
>> Linux applications requiring Linux security permissions should start
>> their execution path.
>
> We shouldn't condone assigning security permissions to specific win32
> exe files beyond what the user naturally has. Currently, we cannot
> protect the exe process from anything else the user does, so it's
> effectively the same as giving that permission to any user that can
> execute the file.

Please note setcap on a file can also block permissions.   So you can
make a program run with Less permissions than your current user.   The
fact this currently cannot work its both ways.

http://linux.die.net/man/3/cap_from_text
Most setcap for capabilities are done using the + operator but a -
operator is supported to take capabilities away.  So a setcap with
all-eip is fairly run without any of the users assigned capabilities.

So this is a double sided tech that cannot be used at the moment.
>
> Of course, giving special permissions to wineloader is ALSO the same
> as doing that, but the solution is to give the permissions to the
> target program in some way that actually works, rather than switch to
> a different way that doesn't.
>
> I would suggest running these programs in a dedicated account.

Even switching away you have to know when the application has or has
not got the permission.   Using binfmt-misc the wine loader program
still will be run first and it can still drop the flags.   This is one
of the advantages of capabilities.   Even switching to another method
you really do need to tag what applications are using raised
capabilities.

>
>> Really the MINE type usage by .desktop to run wine should disappear
>> for Linux other than to tell the  system
>> to directly execute the exe.
>
> The use of wine.desktop to run executable files is intentional and
> necessary. This is because Windows runs executables differently
> depending on whether they are invoked from the command-line or from
> the GUI (windows explorer). There are several differences, but the
> most important is that running from the GUI sets the working directory
> to the parent directory of the executable. Many applications rely on
> this behavior and won't be able to find their own files if they are
> executed from a different directory. Use of wine.desktop runs
> executables the way explorer does, which is appropriate when a user
> double-clicks the file.

Yes but the reality here is it broken.   Anyone using multi prefixes
there is nothing to tell wine.desktop what prefix it should be.
>
> We don't want to change the working directory when running an exe via
> the command line because windows doesn't do that, and because it can
> be important.

Also running command line program by gui there is nothing to tell
wine.desktop at the moment it has it wrong.   So this is another thing
that is broken.  There needs to be somewhere to record this.  Is the
program commandline or is it gui.  The fact it not recorded causes
failures.
>
> It's not possible for binfmt to determine how it was invoked, and thus
> which behavior it should use. AFAIK binfmt is generally configured for
> the command-line mode and is not suitable for GUI applications.
>
> Binfmt can't tell us which interpreter to use with any more accuracy
> than the desktop environment, unless it's specifically configured by
> the user, and in fact binfmt has a harder problem to solve because it
> doesn't know whether to treat the exe as a GUI application (whereas we
> can assume anyone using wine.desktop to run a .exe file wants the GUI
> mode). At least with wine.desktop, this can be configured through the
> same GUI that will be used to run the file, which wouldn't be possible
> with binfmt. For most users, that one setting will be enough.

This is the point of having a manifest file.   Yes a user may not be
able to alter the binfmt-misc settings themselves.  But the
exe.manifest file is the users file.

Some else a binfmt loader can in fact check a limited amount.
http://linux.die.net/man/3/isatty  This only returns true if the
environment is text based interactive.   Something started straight
form KDE/Ghome/most Linux graphic file managers this will return 0.
Ok it also returns 0 when running in a script.

Also you have forgot very much that xdg-open exists.  So assuming
wine.desktop is GUI is a balls up as someone could have done xdg-open
some.exe.

Reality is by either .desktop or binfmt solutions you do need to run
proper execution location determination or have some file recording
what mode application should be running in.

Yes you should be checking isatty in the wine.desktop case that is
currently not happening so that the xdg-open case is handled correctly
right?   Ok now with xdg-open some.exe how are you going to tell your
loader program that is gui or console..
>
> For users that need to use something other than wine for only some
> .exe files, the sensible thing to do is create a shortcut (.desktop
> file, shell script, or whatever is most convenient) that does it in
> the right way. That has the advantages of being a generally useful
> skill that users are likely to already know or at least use again, and
> of not relying on the user to have binfmt configured in a specific
> way.
>
Ok so we expect users to be interactive.  Great.
>> Even .desktop files to run programs under Linux should become super
>> simple.
>> Path to executable as enough.   All the extra complexity in the
>> .desktop files for Linux is a bug.
>
> Generally .desktop files correspond to .lnk files, not .exe files.
> Links to executables are just one specific case. And more importantly,
> putting some configuration file next to a .exe would require user
> intervention, while we can create .desktop files automatically.
>

What there is now a problem with users being interactive and doing
things.     Sorry you cannot have this both ways.

Also most exe that users would be wanting to straight on click on will
most likely be the ones that have lnk files.   So when the .desktop
file was generated so could have been the .manifest file next to the
.exe.   Even if .desktop generation was disabled by user the manifest
could have been generated.   Currently with lnk files to desktopl or
nothing.   Generating a file next to the exe would give us 3 options.
 lnk file to ,desktop and .manifest or lnk file to just .manifest or
nothing.

Basically binfmt-misc configurations are broken.   wine.desktop is
broken.   Both go ahead and make massive presumes of 1 that the user
will not be using multi wine prefixes/versions.  2 that the mode of
execution will be 1 way or the other instead of recording user intent
and probing.

Peter Dolding