Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.
VSTa Capabilites VSTa Capabilities are the way by which VSTa defines it's analagous to POSIX object security. It is a very general system, with a simple design, and high flexibility. A look at how the POSIX system maps into VSTa Capabilities will make it's operational syntax clear. Recall that POSIX defines other/group/user, defining your increasingly close relationship to an object. In parallel with this, it also defines some bits which describe what you can do to an object based on how close your relationship is to the object. For instance, a mode of 0751 on a file owned by group 9 user ID 11, means that user ID 11 gets all three bits (Read, Write, Execute), group 9 gets Read/Execute, and others get just Execute. Now, let's restate the exact same protection system in a different way. First, the question of "closeness" is simply the question of how far a UID matches a protection ID. So if you are (in POSIX-ese) group 9, user ID 11, then your ID would be: 9.11 And when you look at a file, it has a protection which might look the same: 9.11 Finally, in parallel with this file protection you get a matching set of bits which tells you what to grant: 1.5.7 Which, matching from the least specific to most, says "other" gets 1 (execute), group 9 gets 5 (read+execute), and user ID 11 gets 7 (read/write/execute). Now, if you're still in group 9, but your user ID is 12, then your ID: 9.12 Matches the file's protection ID up to 9, but not through 11 any more. Thus, of the 1.5.7 bits, you get 1 (everybody does), and 5 (because you matched through 9). You don't get 7, because 12 doesn't match 11. Thus, the VSTa protection scheme is a simple generalization of POSIX's 3-level scheme. Instead of only allowing group.user, the dotted numbers can be longer, describing a hierarchical ID space which can be organized as needed. Also, all the nasty special cases of group lists, saved UIDs, effective UIDs, and so forth are mostly subsumed by the generalization that a user (rather, his processes) can have an arbitrary number of IDs. Access to an object is the sum of access gained by each ID held.