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

[Vincent Povirk]

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

Then I should note that the limitation works both ways as well: we
cannot currently protect other wine processes from one that has fewer
permissions than the current user.

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

I don't see why this is. Can't the appropriate permissions just be
assigned to the user that will run this software?

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

It's intentional that we don't expose multiple prefixes in the UI of
plain Wine. The idea is that it should just work "like Windows", and
Windows doesn't have any concept of prefixes. You just run your
installer and then run your program from shortcuts.

If you've set up multiple prefixes, you've already used the command
line (or an external UI) to start a program in a different prefix, so
you can certainly do it again.

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

If you started a program from a command line via wine.desktop, you've
probably used xdg-open which doesn't allow command-line arguments.
There is no good reason to do this (except if you know you want to
start the program in the gui mode, and don't know about 'wine start
/unix').

If you started a console application (which is NOT what I mean by a
command-line program) via wine.desktop, Wine will create a console
window for it, just like Windows. When I say "command-line program", I
mean one designed to be invoked from cmd.exe, rather than
explorer.exe.

This is a case where being "like Windows" is the least surprising
thing we can do. Normal people don't know that cmd and explorer start
executables differently. However, they DO know how their software is
intended to be used and will naturally use it in that way.

Being better than Windows in some weird corner cases, and then only
with user configuration, doesn't seem worth the complexity here.

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

This is only worth it if we want to encourage use of binfmt with Wine,
which I don't think we should do, given that the only known use case
for binfmt+wine is one we can't functionally support.

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

Your solution requires manual intervention all of the time, while Wine
currently only requires that in some cases.

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

We can't automatically put random files in application directories
next to executables. That's likely to break applications.