Re: how do capabilities work?

[eagle@zk3.dec.com writes:]

>I like what it says the consequences are, i.e. - a user
>can create new user IDs with a subset of his/her own
>privileges, but I don't understand what all these dot-separated
>numbers represent. Can anyone explain this?

It's very simple in practice, but difficult to describe. Let me try
describing it from a POSIX perspective.

Recall that POSIX defines other/group/user, defining your increasingly close
relationship to an object. In parallel with this, they also define 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.

                                                Andy
Received on Tue Apr 12 13:38:26 1994