Wine-Devel

By thread

wine-devel@list.winehq.org

July 2015

61 participants
402 messages

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

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

July 1, 2015

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

by Peter Dolding

On 6/26/15, Vincent Povirk <madewokherd(a)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

July 1, 2015

Jump to page: