Goodness. You go to a few meetings, and the next thing you know,
there's a gigantic pile of email waiting.
I have not read in detail all the previous replies. I'll do that.
And I haven't finished thinking through the issue in sufficient
detail, or talking technical guts with Jim and Pete, to have a fully
formulated idea. I'll do that too.
But meantime, I thought it would be worth saying a bit about the path
I've been going down to come up with a solution for this.
Rough metaphor: each obj in iwhd has perms roughly similar to *nix fs
perms, with a hierarchy of r/w/x bits. Where 'x' is really launch.
All the perm values are represented in MD tags on the object.
"Somebody" defines what a user id is. Could be a string like "jrd"
or
a wacky uuid or whatever. From iwhd's point of view, it's a string
token. I'm not expecting to do any any checking of the token, ie go
look it up in ldap or anything.
One of the use cases is to give specific perms to specific users. So
there's a tag for each user, storing perm bits. The tag is probably
implemented as a fixed prefix against the user id, something like
"user-permission-<user-id>". Objects with only a single user perm are
effectively owned by that user. [NB that this means that there isn't
a single owner, essentially all users which have write access are
owners]
One of the use cases is to give object access to a group. Similar to
user, there's a group tag, something like
"group-permission-<group-id>". [NB that I'm assuming these group
tags
are stored on the objects, not on users. If we adopted a user model
where a user had its own group properties, this could be simplified]
There needs to be a "world" like perm, that's stored in another tag of
the form "world-permission".
With those in mind, any access attempt to an object comes in with
access-type, optional user-id, optional group-id, and world perm mask.
Access checks are fairly obvious: for the user-perm record matching
this user, do I have a perm which matches the type, for the group perm
record matching the group-d, same question, for world, same question.
If any answer is yes, permitted, else not.
There's the issue of create: For that, I propose to use a magic
object, whose tags represent create access on the store as a whole.
Pending issue: Is delete access the same as create access? Or should
it be (write) access to the object which allows delete?
There's a subtle but important issue: Who has access to the tags? I'm
going to declare, as a straw-man, that write access to an object
implies write access to its tags. That means that anybody who has
write access to an image (either due to individual perms, group perms,
or world perms) is able to add new tags to it (giving access to other
users or groups) or delete tags (removing access by other users or
groups). I *think* this is suitably expressive, as well as safe. But
I freely confess I have not thought through everything in detail yet.
Feedback on this point appreciated.
We need a way of doing something analogous to root access. The best
idea I have about that is a shared-secret sort of thing, which would
have to be negotiated between the iwhd instance and clients and some
third party, presumably at start time.
This overall scheme will imply some changes to the iwhd api.
In particular, every access call will be expected to supply at least
one of user-id, group-id, root-key. If none are present, it's the
world rights which apply. NB that the implication here is that
clients such as conductor are expected to pass along user and group
context when doing operations for which they apply. For instance for
a launch, it would pass the user logged in, and the group (pool
family?) in which the launch is requested. If neither of those match,
then it's world permissions which matter. I suppose there's a
corrolary, ie that if you wanted to support a self-service
walk-up-and-launch-stuff model, you could pass both user and group as
null.
The above paragraph applies to operations which imply tag changes,
too.
Every create call will be expected to supply an optional (tuple of
user-id and perms), optional (tuple of group-id and perms) and
optional world perms. I think, given the above-described model, that
if you supply none of that stuff, you get an object which can only be
accessed with the root key :-(
That's it for now. My plan is to think about this more and solidify
it for early next week. Then figure out how long it takes to
implement....