Bindings and permissions

I was thinking about the bindings and permissions stuff today.  I've 
discussed it before but this may be a new take on the subject.  Recall 
we don't really know what the behavior is with dynamically inherited 
ACLs (when a parent's ACLs automatically apply to its child resources) 
when some of those children are bindings to resources that also have 
bindings.  Some of the possible solutions to this:

1.  Directory permissions are not dynamically applicable to children or 
at least to bindings.
2.  You can't bind resources into directories that have different ACLs 
than where they're bound already - server returns 403 or something
3.  Permissions are path-dependent.
4.  Not all bindings are first-class -- there's a "real name" and then 
there are aliases.  The collection containing the "real name" is the 
one that inherits permissions
5.  There's some algorithm for "summing" or "intersecting" the 
permissions according to the parents of all the bindings.

There may be other possible models.

It seems to me clients have no way of knowing which solution the server 
has chosen and behavior can be quite unpredictable.  Is there some way 
to advertise the server's model? Are some of these choices forbidden?  
Of those that aren't forbidden, is one of them recommended?

It would be extremely surprising if the 'bind' privilege grants 
somebody the ability to make a new mapping of a resource into a new 
directory, AND that a consequence of that 'bind' operation is to change 
the permissions on the underlying resource -- without requiring 
'writeacl' privilege.  Since that's a possible security hole, what 
should that be -- a MUST NOT?  A security consideration?

Lisa

Received on Saturday, 17 December 2005 00:13:29 UTC