How can I detect WINE from my program, or detect Linux, in other wors how can I detect that OS is not Windows. BOOL WINAPI GetVersionEx(LPOSVERSIONINFO lpVersionInfo) returns that OS is Vista :D [Question]
On Sun, May 24, 2009 at 1:35 PM, megapup <wineforum-user at winehq.org> wrote:> How can I detect WINE from my program, or detect Linux, in other wors how can I detect ?that OS is not Windows. > BOOL WINAPI GetVersionEx(LPOSVERSIONINFO lpVersionInfo) returns that OS is Vista ? :DWhy do you want to do this? -- -Austin
Because WINE is not emulator :D When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.
megapup wrote:> Because WINE is not emulator :D When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE.Well, I guess you could check if HKCU\Software\Wine exists ^^
On Sun, May 24, 2009 at 2:41 PM, jay <wineforum-user at winehq.org> wrote:> > megapup wrote: >> Because WINE is not emulator ?:D ?When I detect WinXP I use one tuning, when WinVista I use other tuning, and I want to tuning my app for good work under WINE. > > > Well, I guess you could check if HKCU\Software\Wine exists ^^It could be created on windows as well. -- -Austin
Of course, if some company is called Wine of someone wants to pretend Wine is being used then it could be created. But all registry keys could be fake-created and deleted, so why the registry at all hehe :P oh wait.. the same is true for the HDD.. oh oh ^^
Not better. megapup . Its a double sided sword if wine is detectable why bother fixing wine bugs. If wine is reliability detectable applications developers have a simple path to exclude wine. Reason why we have to reserve the right to move any internal part as we see fit so in case of someone excluding wine we can counter. If wine is reliability detectable this can be used by virus writers to attack host OS. Problem is for support wine would have to expose wine version and host OS reason some bugs are particular to like Mac OS or Linux or BSD... Once you know the host OS you can code to syscall the hosting OS and attack it. Downside of giving it up is cross platform viruses become simpler. Downside out weights the good. You would have to give a really good reason why we have to. Giving developers a free pass does not help wine develop. Applications builder are free to ship custom versions of wine if required. LGPL license was chosen to allow this. If you are looking at wine as a free path out of having to develop natively for other platforms it is not megapup. There are two major solutions to your problems megapup. 1) Wine is designed to assist in cross porting of applications to build native programs as well. So if your program is compatible with winegcc and other tools when in build due to header flags wine is detectable. Secondary advantage is that you can take advantage of native paths for load heavy parts. Source level wine is simply detected. Making like program.exe.so binaries allows you the detection you are talking about since program.exe.so does not work with windows but works with wine also these files are platform Dependant ie Linux Mac OS BSD... So providing the required split. A path was already provided basically just required binary for windows and binaries for different platforms. 2) What would be wrong asking user if they are running in wine in the installer or providing a option in application to enable defective work rounds megapup. Thinking defect work around might have usage on future version of windows or clones like reactos. Using a controllable defect correction system would be the preferred method since wine developers still could use your program in bug testing by not enabling the work arounds. There is more than 1 path. To us we have provided enough paths detection reduces the usefulness of your program to us for bug testing. With wine where defects can disappear or be dependent on a particular video card driver or bit of software. Hard coding the defect handling should be last option because who to say in every case the correction you do in your code will not be cased by something you overlooked your end? megapup you could end up harming your uses with the solid detection. If there are good advantages it would be done.
Hello, at first i want to thank you, that at least someone answered, ive been looking for such detection - i also needed to tweak my application, because of wine does not support some functionality. Secondly if someone would bother to update, fix or do something with it, it would be great. Now for the problem: Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel. Actually im not yet sure if wine supports transparency at all.. I found the problem accidentaly few minutes ago, when i decided to try my windows application on my friends computer, who use wine. In fact it worked pretty well(i bow before wine developers :) ), but my good bye screen, who uses this transparency functionality was totally screwed up. I saw only white blank window. And unfortunatelly i cannot develope the project on wine, so i really need to detect wine and just not use this functionality.
majkl wrote:> And unfortunatelly i cannot develope the project on wine, so i really need to detect wine and just not use this functionality.The official answer is that you should not detect wine to use or not use functionality. Instead you should detect if functionality exists and use it when available. This should work on all versions of wine and windows Now it may be difficult to detect transparency, at least I would not know how. But since it is an approved way to handle missing wine functionality that makes it a very good question on the wine developers list.
majkl wrote:> Hello, > at first i want to thank you, that at least someone answered, ive been looking for such detection - i also needed to tweak my application, because of wine does not support some functionality. > > Secondly if someone would bother to update, fix or do something with it, it would be great. Now for the problem: > > Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel. >You could help solve this problem since you appear to be a programmer. Look in BugZilla for transparency issues and there should be some code or pseudo-code to work with. James McKenzie
majkl Number one if wine does not have a test case for a particular bit of missing function it needs to be coded. Of course there are the odd function or two were you cannot use a detect. Seams strange to windows coders at first is that the best way to detect wine and other emulators is the person sitting behind the keyboard. Problem with those render errors some of them are not wine but the video driver being used too. World of Warcraft of all things has a game config file you edit to enable overrides. This is perfectly fine to wine users. Basically include in instructions enable this to make X problem go away. Advantage of this method is simple the day wine does support doing that you don't need to release another binary with you hack removed to restore full function. If you can detect using normal windows calls if a function is working on not use that. If you cannot simply use a configuration in file or registry for the application. Detecting wine itself is the wrong path.
Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail. I was not talking about secuirty through obscurity as such. We provide a detect path we are able to limited so cannot remove it. If we find an attacker using a detect path we have to have the right to remove it we can limit the damage that can do. This is where the problem comes in with all the forms of detect so far. You are going to hook to something that we one day may remove. So then we get yelled at if we say do that. There is a really dirty way to detect wine and it is the most dependable by the way. Try to run .exe.so if it runs it wine or another emulator base off wine. If it don't run it not wine or the wrong platform type. You can catch this failure by the way. Again can be secuirty filtered against to stop it from functional operation. You could also allow the file to be removed if missing going on as if you are on windows. So meeting our requirements. This kind of support is not going to be removed because someone decides to abuse detecting wine. We already have a built in counter measure. dll overrides settings. Flip the default if dll is not listed as builtin don't allow it to be loaded as builtin. So detect would be dead as door nail if we ever had to kill it. Yet restore able by altering winecfg libs for the application. Basically at some point you many have to tell user how to enable the extras anyhow. So why not just be up front and ask them. Simpler by the way don't have to include .exe.so for linux bsd mac os solarias... Detecting wine is the hard path. This way is using nothing about the internals of wine. The complete idea that you have to add something to detect wine is wrong. If you are after a way wine users/developers cannot block if they choose to forget it. That is impossible. Basically you guys are thinking the incorrect ways. Test function is the way. Not like windows is going to add elf support any time soon. Gert If you want to call system native in the first place .dll.so and .exe.so are the recommend to do it. As we say function tests. If it functions you have wine if it don't you have windows. Gert wine always has overhead. Interfacing with native dialogs sound like a way to save a lot of coding hell. Until you wakeup. Native dialogs on Linux are basically incompatible with windows. http://wiki.winehq.org/WinePluginApi Yep inserting a windows gui addon into gtk or qt currently is impossible. So you will have to rebuild your full front end native anyhow to have it work. That is basically most of the way to building the full program. Then there are threading control issues and other evils. You are talking a major undertaking. It gets to the point bugger it port program to QT will be simpler. Also thinking upcoming is arm and mips based processors so a port to QT or Java will be worth it. Low end of market will own to arm/mips process running Ubuntu and other full distrubtions, android and Windows CE. Sorry wine don't run on arm without being wrapped in qemu and being as slow as hell. Really have to look carefully for why to go the path you want Gert. Long term for most programs using wine as cross platform interface is wrong answer. It would be nice to have pass through libs in wine for qt and gtk we don't because it will hurt like hell. Even simple things like a file handle don't match up. If someone wanted to provide wrappers for that they could.
oiaohm wrote:> Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail.Also with a fully active Firewall & Antivirus (where every executable must be authorized manually by the end-user) a Windows system is mostly secure against attacks. But this is not the common case, that's why viruses and trojans are still doing damages on Windows. The default installation of Wine has Z:\ active, so the majorty of Wine installations has vulnerabilities from someone who targets a Wine-Linux system. And simple relocation doesn't help since I can use winepath to get the current path. I even don't need the access to the full / path but my default home directory is enough, since I'm a "bad guy" my code contains also a copy of the native /bin/ln executable located in C:, so I only have to run C:\ln -s / /home/currentuser/.wine/dosdevices/v: After I did some damage (on v: which point to /) I can safely remove that symlink again. But maybe this is even not necessary since a symlink created in such a way is not visible in the WineConfiguration program. And you get the current user path through the environment or through winepath. But.. why all this hassle? Since I am attacking a linux system I only need to have my malicious code compiled as a native Linux binary. No need to have any symlink at all. So another good way to know if I'm running on Wine/Linux is to run my own compiled linux executable, if it runs then I'm on linux. I just discovered yesterday that it is possible to run native linux executables within wine. oiaohm wrote:> The complete idea that you have to add something to detect wine is wrong.Many small issues in Wine will never be fixed because - it's not worth (or) - there are too few developers to fix everything (or) - the wine community does not want to fix something by design (or) - some issues are just impossible to fix due to technical reasons In such cases a workaround is the only solution (also just a messagebox saying that a specific feature is not available), and such workaround require to know if I'm running under Wine or not. And since there exists already many ways to know if I'm running on Wine. Why not offer a official standard way that will work reliable for the good guys? Bad guys will find out in any case.
Ok, i understand that you dont want to have reliable way for everyone to detect wine from application - i understand, there may be good reasons for this, it depends in point of view, but what about this switch/option/configuration stuff, that someone above already mentioned? What about saying wine to allow the application to findout if it is wine, or not allowing it? Would it be hard to implement such switch?
Sjors Gielen wrote:> IsWineBugFixed() sounds like *totally* the wrong way around.Ok, let's forget that function. Was just an idea, no need for it. And I understand the viewpoint that Wine - want to make applications looks like Windows - doesn't want to use hacks to make more Windows programs run (better) But since more than one developer here wants a different behaviour for his application (see my previous message) we only ask for a simple "getNativeOS" function. Then it's our trouble to handle the wanted customizations (in my case the use of the native Finder style for Mac OS X and the native Nautilus style for Linux to handle the file dialog boxes (just an example). I want a more user-friendly application and not an exact copy of Windows. Also is it possible to run always own distributed native linux/mac binaries even with a hardened Linux sandbox?
austin987 wrote:> Native dialog boxes aren't allowed, many programs depend on certain > nuances of the native dialog boxes.We don't ask for native dialog boxes, it's against the Wine viewpoint, and this is accepted. We ask for a simple getNativeOS function. So that we can use our own native linux/mac binary to do whatever we want for a more user-friendly application. austin987 wrote:> > > Also is it possible to run always own ? distributed native linux/mac binaries even with a hardened Linux sandbox? > > Not sure what you mean here.oiaohm said that with a hardened Linux/Sandbox it's not possible to run 'other native binaries', is this true also for my own distributed native linux binary or only for the binaries outside the C: symlink?
andreaplanet> So everyone who want to detect Wine must create his own exe.so? Ok, but if it is hardened through a sandbox then still can I run it? With a sandbox can I run a native linux binary distributed together with my application?Reason exe.so are loaded by the wine loader. Same as your .exe if sandbox blocks the wine loader exe's of either form will not load so for wine to work it has to allow it. Now wine loader on the other hand can be set to refuse it. You can provide users with instructions to get around that. AppArmor no. Selinux and smack harded yes. Selinux and smack can rule out program from loading other native programs completely with wine. Unless Selinux or smack approves you program to run particular native programs it cannot under hardened this even applies to native programs. Really makes attacking linux servers that are hardened fully pain in ass. Just coping in a elf file and trying to run it on a hardened system just sets off the alarms. To be correct selinux or smack can take ext-ream offense to it and terminate a program for attempting to do something it did not approve. Selinux can also restrict the native .so files your programs can talk to. So if wine does not use a .so file and you decide to reach out and use something wine does not use you can almost bet in a hardened system you just got the application killed. Selinux or smack when it terminates a program will not give program notice that it is doing so. It will just simply clean the program from memory. Its not something you want happening half way threw a write. Linux's hardened are a complete different game to windows. Linux does not take the soft method of answer you were not approved to do that. Simply just kills the program. Yes Linux systems can have a hitman standing over your shoulder waiting to take your application out. exe.so must only be Dependant on win32 dlls provide by wine and the right platform not to risk being blocked by a sandbox. Even probing can get touchy if wine passes a wrong platform elf to system because it don't id as a exe.so selinux and smack can kill application. Sandboxed to hell. There is no way out. This is why I am saying it is better to tell the user and provide a wine tickbox and the like so user ticks wine and you can include like this program will use the following extra native parts please make sure wine/application has secuirty permissions to use them. Anything native person sandboxed many need to turn off. Also the reason why you might have to provide more than 1 workaround methods. Ie one using replacement win32 dlls and one using native parts. Reason why I keep pointing to the installer. The difference dealing with a OS who secuirty system can truly work and has the mind that a harmless program killed by mistake is better than letting a harmful program pass. By the way AppArmor is a complete joke of a mandatory access control system. Its not included in main line kernel because its file access controls can be bypassed. Someone really need to update it to support the secure path based system provided in 2.6.29 and on. Bug numbers sound fine in theory. Until you wake up Wine bugzilla has been compacted 6 times so far. Closed bugs removed and new bugs give there bug numbers. Yes wine recycles bug numbers. One of the open bugs is to try to make wine pull theming from user desktop and make wine look as close as native without breaking application compatibility. Wine really does not want to make applications in wine look like windows. Its just side effect from not being able to join the theming engines up.
Also by asking you can ask to run wine itself native with the wine --version flag to find out what version wine you have. There is a good detect path using person behind the keyboard. Avoid person behind keyboard. You are playing with fire. Its a Linux system secuirty is out to get your program. That is the way you have to treat it.
I would really like to second almost everything that andreaplanet wrote, but for additional, different reasons. I work for a company that still supports for some old, not yet retired products, Windows 95 2nd edition up to Windows 7 now with latest and greatest builds. We heavily rely on a custom log file infrastructure that our support personnel uses to analyze what's going on on customer sites. We are talking about a product that runs on dozens of millions of corporate desktops and servers world wide, 24x7x365. As long as an app of ours will not be able to write to its log file, that it runs on Wine, instead of, say XP, no support personnel of ours will be able to distinguish real Windows XP from Wine's "illusion" of Windows XP, so we will never be able to support Wine, period, end of story. In a private project of mine I currently follow this approach: Users will have to specify the Wine version they are running, as a command line parameter. If they don't, the app will either not work or crash with current versions of Wine. There is no other way, otherwise I cannot work around limitations that Wine has, but I believe will not get fixed any time soon, given the fact that I submitted bug reports almost a year ago. It would be a helluva lot easier if there were a way to get the Wine version and let my app apply its compatibility code paths with a priori knowledge it has about certain Wine versions. Hey, I have to do the same thing for Windoze9x vs. NT vs. Windows 2000 vs. XP vs. W2K3 server vs. ..... why does Wine make it so hard for me to help my apps make the best use of it? -- Stefan
Hello Alexandre, Alexandre Julliard wrote:> "Stefan Kuhr" <wineforum-user at winehq.org> writes: > > Check ntdll.get_wine_version(). It's not a good idea to add workarounds > based on the version, but if you really want to, it's there. > >Please excuse my ignorance, but what is the exact prototype and calling convention for this function, so I can do a GetProcAddress on it and execute it? I have searched the Wine sources but could not find this function anywhere. I have Wine version 1.1.22. Thanks, -- Stefan Kuhr
2009/6/4 oiaohm <wineforum-user at winehq.org>:> Bug numbers sound fine in theory. ?Until you wake up Wine bugzilla has been compacted 6 times so far. ? Closed bugs removed and new bugs give there bug numbers. ? ?Yes wine recycles bug numbers.WHAT? What does Wine possibly gain from hiding old bugs in this way? - d.
Hi Alexandre, Alexandre Julliard wrote:> "Stefan Kuhr" <wineforum-user at winehq.org> writes: > > > > Please excuse my ignorance, but what is the exact prototype and > > calling convention for this function, so I can do a GetProcAddress on > > it and execute it? I have searched the Wine sources but could not find > > this function anywhere. I have Wine version 1.1.22. > > > > const char *wine_get_version(void); > > It's in dlls/ntdll/misc.c. > > -- > Alexandre Julliard > julliard at winehq.orgAh I see, it is wine_get_version, not get_wine_version, that explains why I coudn't find it. Thanks, I will give that one a try. Can I expect that this function will remain an exported function of Wine's ntdll.dll in the future? Again, thanks. -- Stefan Kuhr
Vincent Povirk> If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this.Other than the fact the secuirty systems of Linux can watch syscalls. So calling 1 that wine don't use equal dead application. Yes it is even possible to block sys-calls from inside wine loaded exe's from the Linux system itself while allowing the dll.so files of wine perform syscalls. I do keep my eyes on what prototype secuirty systems exist. Wine could make it simpler by the way. Method is what LUK has been doing. Add a set of syscalls to the OS kernel itself for wine. Using anything else could be disregard. Since the syscalls would be emulations of windows it would effectively render you blind. It is foolish to claim something cannot be fixed in software. Software everything basically can be fixed its a pure question of time and resources. Wine does not need to fix this at this stage due to OS secuirty. I was not claiming wine contained a sandbox. Wine can be sandbox by the secuirty system in Linux. So leading to problems. Its so simple to think just because you detect wine that you can now do whatever you like. This is not windows. Doing whatever you like equals dead applications. Problem with detecting wine without asking is if wine is sandboxed you end up doing things that get programs terminated. Most people planing work around most likely are planing to reach out to native code that can major upset the secuirty system of Linux. If your work around sticks to wine and windows based code you are not going to get on the wrong side of the secuirty system. Both wine and the secuirty system of linux are evolving. There is a correct path that will never harm. Ask. You are looking at wine alone and forgetting the OS around it. Not a wise move. David Gerard and austin987 the bug clean outs don't happen often. Its simple case of search ability of database bigger the database the slow it is to search. Result is always a risk of a number being recycled from it. You can depend that a open bug number will never move. You cannot depend that the bug number in like 8 years time will refer to the same bug. Bugs are designed to be temporary records not record for all time. Also recycling of the number does not happen straight a way. You are talking years at least from the time it was taken from closed and sent to void before its reused. Problem here we still have people wanting to run in wine programs from windows 3.11. So any application using wine could be still in use in a 100 years time at the rate things are going. Since it been on codeweavers server have been taken care of the bugzilla its been the most stable in its history. Problem here you do have to think longer time scales than even the time codeweavers has assisted wine. Before locking yourself into something. Wine version numbers are for all time. Those will never be deleted from record due to needing to search. So never risk being recycled by mistake. One case of bug recycle was caused by server crash by the way was not noticed for a few months then it was corrected. That could be enough to really screw up an application. History tells us not to trust bug numbers absolutely. They are data and open to problems. Wine has a really long history and only 6 major upsets in that time is a really low number. Its very much like earthquakes. If you are in a zone they can happen you build house earthquake resistant. Thinking longer than 5 years is something really different to what normal windows coders have to do. This is where we are butting heads. I am thinking huge timescales and history.
PS Wine runs on FreeBSD as well as Linux. Freebsd Jails allow you to reorder the syscall table anyway you see fit. So syscalling out could be syscalling to kill application. Basically syscalling without knowing the OS and Security under wine is a fast way to get application killed.
Protected loads of dll.so files can also be limited. You are describing same kinds of exploitation faults these secuirty designers are working against. System call protection prototypes also prevents from entering libs through non exposed calls. Ie if the dll.so does not export it there you cannot enter execution there. The branching attack is included. From a wine point of view a .dll.so rendered not patch-able would not be a issue. Wine would work normally. Only programs doing things they should not be doing would be effected. Then if program wants to patch dll solution would be to provide a normal dll without syscall usage. It is secuirty evolution. Major reason for security personal going after protecting .so is to reduce down the area exploitable. The alteration makes a major difference. If a executable gets flawed and a .so file is using a higher function in a restricted way attackers options are now limited. Compared to executable gets flawed since access to syscall was provided to the application attacker can use syscall any way they see fit. People have already thought up attacks like yours Vincent Provirk and used them against native Linux systems. So secuirty is evolution happens over time to render it useless. This is how Linux and other OS's like it react to secuirty problems. Any application running in wine could find themselves completely walled in. Not by wine but by the OS around it. By the way Vincent Provirk lot of nocd hacks and game cheats trip straight up over Linux secuirty even when it set on low because they try to edit forbin memory sections. You are making a very big presume you are allowed to alter .dll.so in the first place even in memory. You don't have to be granted that right. The complete thing can be marked no executable and read only in the executable sections until call to .dll is performed. This does reduce buffer overflow flaws getting into executable memory by the way. Yep entry points can be 100 percent restricted. Editing is out. .dll.so not on a approved list by system secuirty also would not run syscalls either. This is why presuming you have a hole in Linux secuirty is bad. One day it will be taken away from you and your application will snap. It will produce a nice little secuirty report saying what you tried to do. You are simply failing to understand you cannot design under Linux and expect to use any form of secuirty hole. Doing so is asking for your application to fail. The point here is if user knows what you want todo. They can open up the security system so you can. It is the application developers fault for the failure because they are trying to treat Linux like windows. Ie can just hack around anything. Linux will not take that method all the time. If your application need to reach outside wine you simply need to be truthful.
Funny enough limiting entry points does not cost that much. Average .so calls on Linux are still less than the windows call to a dll when anti-virus is running. Pax did it on Linux for a long time. Again presuming non exported memory zones have to be marked read write when in application context. So the internal memory structs of .so can be off limits. This is currently not done without real high need. There is no exploit there that the code for the complier and mandatory access control systems cannot activate. It is a simple case of ownership tracking. Simple reason that you are not getting. Linux secuirty could be set like fort knox. Its designed to lock the system down to make any attack as hard as possible minor costs to performance are tolerated. The cost is way less than running an anti-virus on windows. Linux hidden heuristic anti-virus is the mandatory access control system. Yes there are two paths to do heuristics. One is have a stack of signatures and search every program you run against them that comes with about a 20 percent cpu overhead. Or the second remove means to tamper that comes with about a 2 percent cost. Linux has chosen the latter yes locking entry points and internal memory in selected .so files cost nothing compared to running signatures on everything. Normal win32 applications running in wine will never need to reach out to the OS. So mandatory access control profile creators would be perfectly in there rights to forbid this. For the small numbers of applications that do it rules could be customized. So maintaining max strength against intrusion. Informing you uses that you require to do this is required so mandatory access controls can be opened up if required. Large section of wine dlls can be built for windows by the way. So don't interact with Linux syscalls directly so would not need to be protected from tampering. For over 90 percent of all windows applications out there the mandatory access control policy could be set to max on all syscall locations with memory protection and rest of wine forbin from using syscalls. Because the dll you normally would tamper with under windows have no ability to do anything to breach the sandbox. Even if there was a reason why you need to tamper with a protected dll this is still no reason why the syscall could not be moved into a internal and controlled .so that does not exist on windows. In that case application trying to directly access internal .so could be classed as an attack. One of the prototype mandatory access control systems does flow monitoring between .so files. There is no way out. You have to accept this. If there is a way around the mandatory access control system you have found a flaw in the mandatory access control system that needs fixing. If user does not want you going to / they can set it in the secuirty profile on wine. You go around the drive mappings could land in instant application termination even using the mappings you cannot presume you have been granted the rights to run /bin/sh if you have not asked for that right. Linux developers are use to these restrictions. This is why applications have list of parts they depend on under Linux so secuirty can be set right for them. Instant termination when a person is half way through working on something does not make them happy with you. You have just become what you would call an anti-virus false positive that blocked your program from running and terminated it. Basically you are talking about breaking a anti-virus. Should not a anti-virus kick you in the teeth for doing something strange. Linux mandatory access controls have not worries about doing it. If Linux does come under major threat from viruses its mandatory access control systems will have to be turned up. Effectively closing the door on the viruses and any miss behaving applications.
vitamin wrote:> However keep in mind that fixing Wine is always a most preferred solution.8 month ago I reported a bug - together with a suggestion how to fix it inside the source code. I was just one line to change. This week the fix has been overtaken. I'm sorry, but I for myself really not motivated to assist a team who needs so much time, if I suggest a fix directly inside the related source code. I'm thinking to allow the usage of my shareware application under Wine for free. So native Windows user should pay for it - but not Wine users. I'm thinking about this to support Linux and Wine in respect of all the work. To do this I need a way to detect Wine as well. So imho this is a good reason to allow Windows programs to detect Wine. Since Wine is still very buggy and I'm not motivated to bother my users 8 month with a Wine bug - I would implement work a rounds into my application. For this I need to detect the Wine version as well. PS Please do not answer this posting. This is not a request about help - it's a note to think about it...
Vincent Povirk ignorance is bliss. Selinux strict policy for Wine makes attempting to run /bin/sh a fatal mistake for application. Reason wine itself never uses it same with trying to read /proc or /etc again wine does not interface with lots of stuff in there. Sorry Vincent Povirk you are the same as may Windows developers who have driven businesses nuts on windows trying to run in a limited account. Most systems in the Linux world don't have selinux set strict. Either you are coding for Linux or you are not. Coding for Linux and respecting businesses who could use your applications demands no secrets. Highest percentage of people running selinux strict are doing it for business secuirty reasons. All coders would be wise to follow the old school Linux developers and document what features that may require special permissions your applications use some where. This does help people running OS's restricted. Idea of breaking down on processes selinux already does that. Breaking down into libs selinux already can do that. Simple fact the process as a security divide point is old school. It has been found to be far to broad and dependant on application developers to deal with secuirty problems. Sorry business and others may have to run insecure applications and use the secuirty system of the OS to render the security flaws useless to do business. The very thing you said about everything having possible flaws is the cause of finer and finer controls. Tahtu there are a lot of reason why some bugs take ages to fix. 1) Patch is not made aware to project maintainer is very high up there. 2) Patch submitter not following up on patch to find out what was wrong with it. 3) Patch being a hack. Wine rules for patches say implementation of features must be done where able. Not just answer what application expects. I know from personal experience with rollcage I created 8 different patches only to have one of the wine3d developers be telling me sorry you have missed. That breaks a stack of other applications. I was problem hiding. In the end the wine3d developers I was talking found the bug it was that rollcage was being that 1 feature too many existed. Turned out rollcage was badly coded windows never for that application ever told rollcage that a feature existed. Yet if you used MS direct X software rendering rollcage would get told the feature existed and screw up exactly like wine was. Turned out hardware drivers never did tell old applications that that feature was on offer. So really wine was never truly wrong. Its been corrected to match hardware answers since. I spend many months in irc and the like with both of us trying to work out what in hell was going wrong. Idea that bug fixing is a straight forward process is wrong Tahtu. Talking to developers in mailling list and irc are useful tools.