Michael Smith wrote:
b) We still (with OR without this change) have the problem that the history implementation is very broken if you're using access control. It's a hard problem (the semantics of full access control across a versioned repository could be difficult to define), but the current approach basically just ignores the ACLs entirely - so anyone can read objects from their history locations (obviously, this requires _finding_ those objects, which isn't easy, but it's not too hard either). I think we really need to think about what solutions we can come up with for this problem.
Anything you can propose to get this started?
Oliver
I can try...
One possible set of semantics is as follows (note: the following extensively uses DeltaV terminology, it'll be hard to follow if you haven't read the spec):
Normal ACLs do not apply to /history. Or perhaps they do - but generally, the only ones set will be inheritable ones from /, we can deny those same permissions in /history.
When a version resource (VR) is created from some versioned resource, the set of applicable ACLs is computed (from the versioned resource) and set on this VR (note that this isn't just copying them, because we want inheritable permissions to come through as well). I haven't thought through all the details of this, but I think it can be done.
This means that, when a VR is created, _that_ version (but not other versions) has the permissions that the versioned resource had _at the time this version was created_.
Problems:
What if you want to retrospectively change the permissions (e.g. I create version 1, then set permissions correctly, then create version 2. I realise at that point that version 1 had some confidential information in it, should I be able to set permissions explicitly on that older version? Should, instead, the _current_ permissions on the versioned resource always be applied all versions?
What about VHRs? What permissions do we set on those? If permissions on a resource are set such that all users except the person who created the resource cannot even see that the resource exists, it makes sense that the VHR cannot be seen either. But there's only one VHR, so which set of permissions do we use? This problem is easier if we take the "current permissions apply to all versions" approach.
Does anyone know what existing systems (not neccesarily deltav) do? I have no personal experience with any other system that provides both versioning and full ACLs.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
