[Bug 26256] New: wine64-preloader can't handle setcap cap_net_raw+epi
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(a)winehq.org ReportedBy: nerv(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 --- Comment #1 from André H. <nerv(a)dawncrow.de> 2011-03-01 13:16:00 CST --- same thing happens for wineserver, of course that all works for the 32-bit versions -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 Eric Pouech <eric.pouech(a)orange.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)orange.fr --- Comment #2 from Eric Pouech <eric.pouech(a)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+ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 --- Comment #3 from André H. <nerv(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
https://bugs.winehq.org/show_bug.cgi?id=26256 --- Comment #4 from Austin English <austinenglish(a)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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 Andreas Christ <andreas.christ(a)runbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas.christ(a)runbox.com --- Comment #5 from Andreas Christ <andreas.christ(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 farmboy0+winehq(a)googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |farmboy0+winehq(a)googlemail. | |com --- Comment #6 from farmboy0+winehq(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=26256 --- Comment #7 from Andreas Christ <andreas.christ(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=26256 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |focht(a)gmx.net Resolution|--- |INVALID --- Comment #8 from Anastasius Focht <focht(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=26256 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=26256 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #10 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=26256 --- Comment #11 from Sebastian Lackner <sebastian(a)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 -- 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.
participants (1)
-
wine-bugs＠winehq.org