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

[Peter Dolding]

On 7/1/15, Vincent Povirk <madewokherd at gmail.com> wrote:
>>> 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.

Cannot currently is mostly that those cases have not had to be
considered because they were not possibilities.
>
>>> 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?
>
Running software in a different user is not a normal Linux solution.

Like ping you don't run that as a different user.  Ping works because
it been granted permissions.

The fact that wine does not check capabilities.

http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=capsh

Run as a user with a capabilities binding set.   The reality here is
using setcap that does not require root privilage or using capsh as
root to start executable as a particular user with a reduced capset.
 This is basically normal Linux that a user will be running
applications of different capabilities.   Binfmt-misc remove root user
requirement change capabilities.

Basically presuming that users and capabilities under Linux align is wrong.

Please note starting wine by a bash script can also have giving wine
more capabilities than it normally would have if the bash script had
setcap applied to it.

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

Except it never going to.   At least inside the next 5 years.

Works just like Windows is so wrong.   Remember Windows 7 pro had
Windows XP virtual machine.   How did you declare that a executable
should be in the virtual machine the exe.manifest file/compatibility
mode.

So the XP virtual machine is example of dual prefix under Microsoft.

We wish to run a broader selection of application so multi prefixes
should be expected.
>
> 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.
>
You have dropped to command line because you have been forced to so
application work.

Wine does not have a super complex shim system with Application
Compatibility Database.   Without a shim system usage of custom
patched versions of wine will be required at times.

Microsoft Application Compatibility Database has a limited size
because once it gets past a particular size it starts slowing down
running any application under windows.  So the Microsoft method here
is busted.   That this solution is busted we cannot copy how windows
does it or will will copy the exact same problem.

Basically goes like this under Windows.
1 you request to run an application
2 it looks up the application compatibility database and lines up to
apply all shim alterations.
3 it reads all the .manifest files to find out what library the
application should see and.
4 At long last Windows decides to start running the executable.

All the settings in the application compatibility database to avoid
the expand to hell issue is place them in a file next to the
executable.

Yes stacking them in the registry per executable name has the same
problem or worse.  Why worse what happens when you have two programs
that have installed a exe file with exactly the same name requiring
different tweeks.

Currently wine registry method of applying per application settings is
broken.   Microsoft Method is half broken.   Why half broken the
.manifest stuff of Microsofts works.



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

Note what you said here will create a console window instead of using
the already open console.   Yes there is a bug here.
>
> 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.
>
Until win64 works manual intervention to prevent users install
applications that will work in win32 prefix in a win64 prefix that
fail.

Some cases  by number of applications in the appdb its over 60 percent
of cases are going to need manual intervention.  This is not going to
change any time soon.

>> 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.
>
The file I am talking about creating never before caused a issue under Windows.

Windows compatibility mode does .exe.manifest files.  If application
provided one it does exe.1.manifest and so on.  Of course it marks
them hidden and these files have never caused a Windows application to
miss read them.  Why the Windows application never reads them.

So creating .manifest file for compatibility reasons is obeying how
Windows does things.

Only time what I am suggest could cause a issue is a portable app on a
USB key being taken back to windows.   Adding a .manifest file contain
extra stuff that wine understands will never cause a issue for the
application itself being run under wine.   It SXS and Windows
compatibility under windows/wine that processes the exe.manifest file.

Yes putting extra data in the .config file of a .net application could
be problematic as some applications open and edit this themselves.  No
application edits it own exe.manifest file under Windows.


Peter Dolding