http://bugs.winehq.org/show_bug.cgi?id=26256
Summary: wine64-preloader can't handle setcap cap_net_raw+epi Product: Wine Version: 1.3.14 Platform: x86-64 OS/Version: Linux Status: NEW Keywords: source, win64 Severity: normal Priority: P2 Component: loader AssignedTo: wine-bugs@winehq.org ReportedBy: nerv@dawncrow.de
sudo setcap cap_net_raw+epi /usr/local/bin/wine64-preloader
leads to:
/usr/local/bin/wine64: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory err:process:start_wineboot failed to start wineboot, err 1359 /usr/local/bin/wine64: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory
and no 64-bit app can start.
setcap is needed for e.g. ICMP functions or my not yet published wpcap proxy dll.
http://bugs.winehq.org/show_bug.cgi?id=26256
--- Comment #1 from André H. nerv@dawncrow.de 2011-03-01 13:16:00 CST --- same thing happens for wineserver, of course that all works for the 32-bit versions
http://bugs.winehq.org/show_bug.cgi?id=26256
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #2 from Eric Pouech eric.pouech@orange.fr 2011-04-24 15:04:55 CDT --- it doesn't work for 32bit either (did you set the caps on wine-preloader ?) actually, setting a cap changes ld.so behavior (it no longer honors the LD_LIBRARY_PATH) A+
http://bugs.winehq.org/show_bug.cgi?id=26256
--- Comment #3 from André H. nerv@dawncrow.de 2011-04-25 10:11:24 CDT --- (In reply to comment #2)
it doesn't work for 32bit either (did you set the caps on wine-preloader ?)
i always turn the permission on/off by setting it to wine-preloader (32-bit) i'm running Ubuntu, so maybe that does some strange extra magic
http://bugs.winehq.org/show_bug.cgi?id=26256
Sylvain Petreolle spetreolle@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr
https://bugs.winehq.org/show_bug.cgi?id=26256
--- Comment #4 from Austin English austinenglish@gmail.com --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.16 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=26256
Andreas Christ andreas.christ@runbox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas.christ@runbox.com
--- Comment #5 from Andreas Christ andreas.christ@runbox.com --- (In reply to Austin English from comment #4)
This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.16 or newer) wine?
Yes, it is. A few weeks ago I tried to run a 64bit application on Wine 1.7.13 (built from source on Debian Testing) which has to connect to a flexlm license server and ran into the issue described by the original poster. If needed I can provide more details or help testing a fix.
http://bugs.winehq.org/show_bug.cgi?id=26256
farmboy0+winehq@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |farmboy0+winehq@googlemail. | |com
--- Comment #6 from farmboy0+winehq@googlemail.com --- I built wine from git today. This error happens for me for 32 bit wine.
After running setcap cap_net_raw+epi /home/eho/programs/wine-std/bin/wine-preloader as root wine doesnt start any programs anymore.
The error message is: /home/eho/programs/wine-std/bin/wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory
strace shows that ld no longer searches the wine install path for the library only /usr/lib32/*.
Removing the cap from wine-preloader leads to wine working again.
http://bugs.winehq.org/show_bug.cgi?id=26256
--- Comment #7 from Andreas Christ andreas.christ@runbox.com --- Thanks to Eric Pouech's hint I did some research and found the following:
https://stackoverflow.com/questions/9843178/linux-capabilities-setcap-seems-...
So it is not a bug, it is a feature. I followed the explanations in the link (see the post at the bottom) and added a file (named wine64.conf) containing the location of my libwine.so (in my case /usr/local/lib64) to the directory /etc/ld.so.conf.d/ and ran ldconfig. This resolved the ICMP issue.
Unfortunately, I get a different error message now from the FLEXnet License Finder when entering the server IP: "Network error: Server ("192.168...") not responding..." I know that the license server is up because the application I am trying to run connects to it in a virtual machine on the same host, and iexplore in the wine prefix can connect to the network (both LAN and WAN). The application itself runs nicely with a demo license file (without connecting to the license server). Anyway, I assume that this has nothing to do with the bug as it was reported here originally. So I may open up another case soon unless I can figure out a solution.
farmboy0, may I ask you to reproduce this on 32bit? I do not have an appropriate 32bit application I could test. If this resolves your problem, this bug can be closed.
https://bugs.winehq.org/show_bug.cgi?id=26256
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |focht@gmx.net Resolution|--- |INVALID
--- Comment #8 from Anastasius Focht focht@gmx.net --- Hello folks,
as already pointed out by earlier comments this is a security feature.
There is nothing to fix in Wine.
After adding private library search path to dynamic linker configs ('/etc/ld.so.conf.d/wine64.conf') it works for 64-bit.
Tested with Wireshark/wpcap.
You could add this to Wine Wiki though.
Regards
https://bugs.winehq.org/show_bug.cgi?id=26256
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=26256
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #10 from Sebastian Lackner sebastian@fds-team.de --- While testing Andre_H's new pcap library I also ran into this issue, because I had multiple wine versions installed. For those that are not happy with editing the linker configurations, here is an alternative solution.
The problem is that the executable in bin/wine has an relative rpath set:
--- snip --- $ patchelf --print-rpath wine $ORIGIN/../lib --- snip ---
It is sufficient to put in an absolute path here, and everything works (without any further configuration). As it turns out modifying this executable is completely sufficient - no need to change wineserver or the dlls.
--- snip --- patchelf --set-rpath "$(pwd)/../lib" --force-rpath wine --- snip ---
I am using the patchelf tool here, which can be easily compiled from source (https://github.com/NixOS/patchelf). Might probably also work with "chrpath", or even better, directly setting it when compiling wine.
I can understand that upstream wine probably doesn't want to solve this, but at my opinion package maintainers could easily add a workaround for that.
https://bugs.winehq.org/show_bug.cgi?id=26256
--- Comment #11 from Sebastian Lackner sebastian@fds-team.de --- Follow up on my last message - for wine-compholio we decided to fix this issue by adjusting the RPATH in the configure script.
https://github.com/compholio/wine-compholio/blob/master/patches/configure-Ab... (requires autoreconf)
This way both a relative (preferred) and absolute RPATH are present. When the relative one is valid it will be preferred, otherwise (when setcap is used on the wine binary) the absolute one is used, which will work unless the user manually moves around files which are part of the package ...
Regards, Sebastian
-
wine-bugs＠winehq.org