Re: Structure of history folder

[Oliver Zeigermann <oz...@c1-fse.de>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Structure of history folder

[Oliver Zeigermann <oz...@c1-fse.de>]

To me this sounds good. What does Peter say to all this as I understand 
he has written most of the DeltaV code.

Peter?

Oliver

Michael Smith wrote:
> Michael Oliver wrote:
> 
>> I believe that the current permissions on the current version should be
>> applied to all versions and not the permissions at the time the version
>> was created.  This is how we did it with Livelink and our reasoning at
>> the time was as follows:
>>
>> 1) If a user is removed from access to the current version, this is
>> usually because the owner of the document wants the content of the
>> document removed from view for that user (or group).
>>
>> 2) If a user is granted access to a document, then all previous versions
>> are also granted, for a similar reason.
>>
>> 3) Access to specific versions without access to all versions was
>> possible in Livelink with a concept we called "generations" that allowed
>> a specific version of a document to appear to the system as a separate
>> "generation" document.
>>
> 
> Michael,
> 
> This sounds fairly reasonable. My suggestions before were not intended 
> as a "this is the way it should work", but more intended as a way to 
> spark some discussion of the possible approaches - looks like it worked :-)
> 
> The "generations" stuff looks interesting - but somewhat unrelated. I 
> think we can (should) probably implement just 1 & 2 initially.
> 
> Mike
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Structure of history folder

[Michael Smith <ms...@speedlegal.com>]

Michael Oliver wrote:
> I believe that the current permissions on the current version should be
> applied to all versions and not the permissions at the time the version
> was created.  This is how we did it with Livelink and our reasoning at
> the time was as follows:
> 
> 1) If a user is removed from access to the current version, this is
> usually because the owner of the document wants the content of the
> document removed from view for that user (or group).
> 
> 2) If a user is granted access to a document, then all previous versions
> are also granted, for a similar reason.
> 
> 3) Access to specific versions without access to all versions was
> possible in Livelink with a concept we called "generations" that allowed
> a specific version of a document to appear to the system as a separate
> "generation" document.
> 

Michael,

This sounds fairly reasonable. My suggestions before were not intended 
as a "this is the way it should work", but more intended as a way to 
spark some discussion of the possible approaches - looks like it worked :-)

The "generations" stuff looks interesting - but somewhat unrelated. I 
think we can (should) probably implement just 1 & 2 initially.

Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

RE: Structure of history folder

[Michael Oliver <ol...@matrix-media.com>]

I believe that the current permissions on the current version should be
applied to all versions and not the permissions at the time the version
was created.  This is how we did it with Livelink and our reasoning at
the time was as follows:

1) If a user is removed from access to the current version, this is
usually because the owner of the document wants the content of the
document removed from view for that user (or group).

2) If a user is granted access to a document, then all previous versions
are also granted, for a similar reason.

3) Access to specific versions without access to all versions was
possible in Livelink with a concept we called "generations" that allowed
a specific version of a document to appear to the system as a separate
"generation" document.

Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
 
-----Original Message-----
From: Michael Smith [mailto:msmith@speedlegal.com] 
Sent: Monday, May 03, 2004 8:33 PM
To: Slide Developers Mailing List
Subject: Re: Structure of history folder

Oliver Zeigermann wrote:
> 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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Structure of history folder

[Michael Smith <ms...@speedlegal.com>]

Oliver Zeigermann wrote:
> 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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org