To view parent comment, click here.
To read all comments associated with this story, please click here.
The only way this is possible is if the security privileges are associated with the executable that is running rather than the user who launched that executable. This model doesn't really make sense to me. It would also totally break backwards compatibility and might make the system inflexible.
MS actually already does this with Code Access Security. Code is allowed or denied certain privileges not only based on the user token under which it runs, but also based on attributes about the code like where it came from, the functionality it incorporates, and what the developer has specifically allowed or restricted. More limited features for code trust are also available for unmanaged applications.
How does the OS decide what files Word can work with and what files it can't work with?
The "OS" doesn't. If you completely move file opening into the file manager, as it should be, the file manager knows exactly which files the word processor can modify.
How can we really decide which executable images are even part of one application or two totally separate entities.
I'm not sure what this has to do with anything. If you mean calling one app from another, permissions (obviously) carry over.
What about apps that work together on files?
Still not sure what you mean.





Member since:
2006-01-02
How does the OS decide what files Word can work with and what files it can't work with? How can we really decide which executable images are even part of one application or two totally separate entities. What about apps that work together on files?
The only way this is possible is if the security privileges are associated with the executable that is running rather than the user who launched that executable. This model doesn't really make sense to me. It would also totally break backwards compatibility and might make the system inflexible.