http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #11 from Zeb Figura <z.figura12@gmail.com> --- (In reply to Aaron Rainbolt from comment #10)
I agree with you that Wine *should* not act as a security boundary. Unfortunately, that's exactly what it is doing; by registering itself as a MIME handler, Wine is telling the system "I am capable of acting as a security boundary. If you hand me an EXE file, I can do something the user finds useful with it, without compromising the system." That's what the MIME handler system is for. Of course, Wine isn't capable of keeping that promise, for the reasons you described, which is why I'm arguing that Wine should not be promising the system that it will behave in a safe way.
Okay, I had a feeling that's where this might eventually lead; this position does make sense to me. I don't know why we ship a .desktop and not a binfmt_misc handler. Portability, maybe? It does feel like an oversight that xdg in itself doesn't provide this distinction and relies on other tools to do so (or, well, considers it out of scope? Still feels like an oversight)
That is the implicit assertion in the manpage, but it isn't the focus of this report. The focus of this report is *users don't have control of the files they open.* If a user has Wine installed, any running application in any Flatpak (and probably many Snaps) can trivially escape the sandbox at will, without user interaction. I don't think users expect that installing Wine will break the security model of unrelated applications, even if the user doesn't do anything with Wine other than install it.
Well, I'm not exactly sympathetic to this direct appeal, because I don't think you can argue that Flatpak is doing a reasonable thing here without being able to appeal to xdg-mime and the intent behind xdg-mime. Flatpak tends to do things I find unreasonable, after all... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.