To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander,
"When you have thousands of legacy applications lying around which were never designed for a sandboxed environment in the first place, patching that huge mass of code until it works, like Linux distros which use SElinux or AppArmor try to do, is quite a challenge."
Well this is a given. And it's made all that much more confusing due to the fact that between posix user/group/other bitmasks, ACLs, SeLinux/AppArmor, and NFS shares, the access rights can be totally contradictory. There's just no practical way to determine access rights under linux without actually testing them. The gnome file browser (along with nearly 100% of tools) doesn't even display ACL. I don't think *nix will ever recover from it's POSIX roots.
When I was a windows admin, I never had this problem even with complex DFS file systems across servers.
I'm curious about what MacOS does.
I think I've read somewhere that MacOS X only offers sandboxing as an optional extension for developers to use. People choose to put themselves in the sandbox, so to speak. If you don't use the sandbox, OS X behaves like a normal *NIX
So fully switching to a sandboxed model on OSX would be about as painful as it is on Linux, though with the difference that a large part of the libraries used by OSX developers are under Apple's control. It might help a bit.
Edited 2011-06-26 09:55 UTC




Member since:
2010-03-08
I think your post contains the description of why we're not doing sandboxing in all modern OSs already.
When you have thousands of legacy applications lying around which were never designed for a sandboxed environment in the first place, patching that huge mass of code until it works, like Linux distros which use SElinux or AppArmor try to do, is quite a challenge.
This is why I think that Apple have hugely messed up by not making sandboxing a core part of iOS' design while they could. But well...