[Wine] Re: creating built-in firewall for Wine

oiaohm wineforum-user at winehq.org
Fri Apr 8 02:51:18 CDT 2011


Boriso wrote:
> 
> I looked through http://wiki.winehq.org/CategoryToDo and found no firewall or something similar, but here http://wiki.winehq.org/WineReleaseCriteria?action=show&redirect=WineReleasePlan one could find that "Wine add-ons" are already suggested and this is great. I think that Wine add-ons could made contributions more intensive.
> 

Reason zero point.   Native firewall is good enough for what they provide.  Wine transparency to native system firewalls could be improved.     Native firewall uses does not leave flaws particular if it used how I directed.


> 
> In my opinion Wine is open but not very friendly with sharing information about the project. For example, there are many TODOs, wishlists, information about architecture, user manuals and so on. But there could be some pdf booklet or presentation (even in flash) that explains how Wine works, what are pros and cons, what is left to do. 
> This is kind of a marketing, but good external package is also important. In case you are talking about people who already know everything about Linux, Wine they do not need anything more, but for novices (like me) and ordinary desktop Linux users it is also important. 
> 

There is the wine users guide.  Documentation is a problem.  We are desperately short of technical writers.   We don't have the personal to write the PDF or create presentations and keep them upto date.  We have enough trouble keeping the http://www.winehq.org/docs/wineusr-guide/index staffed as well as keeping the FAQ correct

Lots of the pro and cons we really don't know how long they will stay true.

wishlists most developers don't read.  Better as feature requests in the bugzilla.

What left todo at least the 6000+ open bugs to close is what left todo.


> 
> Anyway, I got many useful information from this topic. I also tested my idea about chaging ws2_32.c and it works fine. Now I'm going to examine Wine deeper.


Don't expect this integrated.  Your path is purely the wrong way.  For the simple reason there is no requirement in wine design for future network interface features to pass through ws2_32.c.   You are basically setting self up for bruising.   Wine dll.so files only have to use windows path pf dlls above them to perform tasks if programs could be effected.   So mshtml emulation lot of places that could be coded going directly to the Linux network stack.  So ws2_32.c would not see those requests. 

This is purely performance based.   Yes this global picture is wrong >  http://www.winehq.org/site/docs/winedev-guide/x2591 <. ws2_32.c most operations don't go up to wineserver or follow NT design so are caught by using native traffic shaping.   Instead ws2_32.c is a jump to native system dll.so.   Other items that are jump to native include wine opengl implementation it avoids following the NT design.  Lot of things inside wine don't follow NT.  Instead follow the fastest path. 

There needs to be extra boxs added to http://www.winehq.org/site/docs/winedev-guide/x2591 marking dll.so ie wine dll files that jump straight out to the native platform.  Wine is permitted to short cut to native where suitable.  This complete stuffs your method of filtering Boriso.  There are going to be holes in your filtering.

Transparency to native firewall is an issue.   I provided the instructions that work around that issue.   Your alteration still does not address the fact the native firewall cannot see the process wineserver is acting for at times.

Its very pointless storing fire-walling data twice and having the filtering processed in two locations.







More information about the wine-users mailing list