vsta

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