> 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.
