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.
http://source.winehq.org/search?string=/bin/sh
http://source.winehq.org/search?string=/proc
http://source.winehq.org/search?string=/etc
That's not never. That is, in fact, sometimes.
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.
You know, I actually tried running Windows in a limited account once.
I discovered something shocking: IT DOESN'T WORK.
This is what happens when you add restrictions on top of an existing
system (instead of, say, designing a new one with restrictions in mind
as Sugar did). Some things stop working. That's the point.
There are, however, important differences between limited accounts and
what you've been describing. When you cross over the boundaries of
what a limited account allows, the OS simply reports an error to the
application. This makes it possible for the application to continue to
function even if it attempts to do something that is not allowed. The
other difference: the boundaries defined by a limited account are
sensible and clearly explained. To function in a limited account, all
that's really needed is to keep settings in the user-specific area
(code/program data can be in a common, non-writeable area or in a
user-specific area as in a "portable" app).
Contrast this with a system in which the security policies are
completely arbitrary. There's no general principle (that you've
explained) governing the security policy. You've described a system in
which every program and library can have completely arbitrary
restrictions imposed on it because "it never needs to do that" and
crossing over these unknown boundaries is fatal.
If a security system doesn't make things easy for me, I won't make
things easy for its users. If I can add functionality to my program by
doing something unusual, I'm going to do it. I'm not going to think
"Oh, but what if someone arbitrarily decided that on his computer that
operation will terminate my program and possibly cause him to lose
work?" I'll fail gracefully and move on if the operation fails, as any
sane system (including limited accounts) will make graceful failures
possible.
If you want me to worry about SELinux, give me general, sensible rules
that I can apply to every program I develop. Don't give me this
"pretend Wine is a sandbox or your program will be terminated" crap.
