https://bugs.winehq.org/show_bug.cgi?id=48889
--- Comment #17 from oiaohm oiaohm@gmail.com --- (In reply to Luca Boccassi from comment #14)
Thanks for the (unsolicited) curriculum, but I'm afraid the only actual, real problem being ignored is that users are silently running a configuration that is unsafe, and that causes them to get their accounts banned, incurring in very real tangible and even monetary losses. So, in reality, the only software acting as malware on my machine right now is wine itself.
No this is you ignoring that there are a 100+ games out there with third party mods that will steal people crypto curreny and bank account information and so on if they are given this privillage.
So this is two groups of parties that risk losing money. Yes there is a group who is not your group who will lose money.
Fortunately someone already documented this broken behaviour in the applications DB pages, to help limit the damage. Unfortunately the workarounds are not "sticky" due to the nature of packages and file-based capabilities - which means at best users could be pinning the versions and avoiding updates, at worst the malware-like behaviour gets reintroduced without notice. Trying to be a good citizen, I thought of sharing a more durable workaround that doesn't require pinning, is a one-time configuration and is still under the developers control.
There is a more durable work around write a privillage script to start the program need capabilities using capsh
https://churchman.nl/2019/03/14/granting-capabilities-using-capsh/
File based capabilities are a sledge hammer that you don't have to use to achieve your ends. capsh route allows starting a bash shell with cap_net_raw and run wine from there and only that instance has cap_net_raw enabled.
What is documented on the appdb page is the most unstable solution and most unsafe solution that you have proceed to duplicate.
Thanks for the suggestion, and I'm truly sorry, but due to the completely uncalled for aggressiveness of your colleague, I lost any and all interest in helping out on this any further.
You are wrong is not uncalled for aggressiveness from me.
Sometimes when you are running into trouble repeatedly it sometimes because you and everyone else is going the wrong way.
Basically file capabilities are not sticking because you are using the wrong option.
Creating a script that could have a stick bit on it to use capsh to lift a single wine prefix up with raised capability is possible. This does not cause the other security problems.
Patching wine so it drops the capabilities on all bar listed wine prefix would achieve the same ends.
Then you have what you are doing that is a security mess with the two options you have tried.
Those who have been writing the stuff in the appdb have not understood what they were using.
The original instructions in the FAQ are old and capsh was not an option back then in most distributions. Yet since I have not updated no one else has and no one else has done the research on the options to set capabilities.
Anyone who did a little bit of homework would have come across the capsh option.
See your problem the complete time is fixable without. 1) changing packaging 2) using file capabilities.
So when you are going the wrong way not understand what you are using exactly why should I not be annoyed.