John R. Dunning wrote:
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".
From iwhd's perspective, for user/group-based permissions to be
useful,
there must be some authentication. Otherwise, user A can simply do
whatever they want by claiming to be the more-privileged user B or a
member of group G.
So iwhd is going to perform authentication?
This is surprising enough that I'm wondering if I've misunderstood...
Some fundamental questions:
- is this proposed implementation intended to be permanent?
Breaking iwhd's API is one thing. If we end up breaking it yet
again when ripping out this temporary measure...
- what is this permission model supposed to accomplish? i.e., what is
the threat model? If knowing the form a request takes and forging
one is all it takes to subvert the model, then what is it worth?