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.
