RE: [ACL] RE: lock and access control lists on (working) versions

I believe Yaron was just saying he both wanted "what the ACL was at
the time it was checked in" (i.e. a historical record, that
presumably could be re-instated with you "update" a VCR to select
that version), as well as an ACL that actually affects who
can access the version.

My response is that in practice, nobody does anything like what
Yaron describes, and so we can leave it as a "server value add"
for now.  Realistically, you won't get all that much interoperability
from ACL's anyway (although they are a lot better than nothing),
so the chances of any significant interoperability benefit from
defining a standard way to access historical access values is
vanishingly small.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]
Sent: Tuesday, June 12, 2001 6:45 PM
To: Yaron Goland; Clemm, Geoff; ietf-dav-versioning@w3.org
Cc: acl@webdav.org
Subject: RE: [ACL] RE: lock and access control lists on (working)
versions


Isn't "the ACL list it currently uses to decide who gets to see the version"
the ACL on the version history resource, or is what you want a version-
independent ACL that applies to all versions of a resource, that can
override the ACL on that particular version?

> -----Original Message-----
> From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
> Yaron Goland
> Sent: Tuesday, June 12, 2001 2:29 PM
> To: Clemm, Geoff; ietf-dav-versioning@w3.org
> Cc: acl@webdav.org
> Subject: RE: [ACL] RE: lock and access control lists on (working)
> versions
>
>
> When I version a resource I will also likely want to version the access
> control list it had when I 'froze' it. This is very important for things
> like security checks. Imagine that an employee who was fired a year ago
> turned out to be a corporate spy, you are going to want to check what
> resources he had access to back then. This means that a version
> really needs
> two sets of ACLs. One if the ACL list it had when it was frozen. The other
> is the ACL list it currently uses to decide who gets to see the version.
>
> > -----Original Message-----
> > From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
> > Clemm, Geoff
> > Sent: Saturday, May 26, 2001 8:27 AM
> > To: ietf-dav-versioning@w3.org
> > Cc: acl@webdav.org
> > Subject: [ACL] RE: lock and access control lists on (working) versions
> >
> >
> > As Tim surmised, the answer to (1) is in fact "yes".
> > Each version is a separate resource, and each resource
> > can have its own distinct access control list.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> > Sent: Wednesday, May 16, 2001 5:42 AM
> > To: ietf-dav-versioning@w3.org
> > Cc: acl@webdav.org
> > Subject: Re: lock and access control lists on (working) versions
> >
> >
> >
> >
> > "Pill, Juergen" <Juergen.Pill@softwareag.com>
> > > Hello,
> > >
> > > 1) Would it be possible with DETA-V to have different access
> > control list
> > > for different versions of a resource, e.g. V1 of resource /foo
> > will allow
> > > user A to modify and read, but V2 of resource /foo will allow
> user A to
> > read
> > > read only?
> >
> > You'd have to ask the ACL-folk that question, but I would sincerely hope
> > the answer is 'yes'.
> >
> > > 2) Would it be possible to have two distinct locks on two different
> > > (working) resources?
> >
> > Yes.  Working resources have distinct server-defined URLs.  They can be
> > locked using their URLs just like any other resource.
> >
> > > Does that make sense at all?
> >
> > Yep.
> >
> > Tim
> >
> >
> > _______________________________________________
> > acl mailing list
> > acl@webdav.org
> > http://mailman.webdav.org/mailman/listinfo/acl
> >
>
>
>
>
> _______________________________________________
> acl mailing list
> acl@webdav.org
> http://mailman.webdav.org/mailman/listinfo/acl
>


_______________________________________________
acl mailing list
acl@webdav.org
http://mailman.webdav.org/mailman/listinfo/acl

Received on Tuesday, 12 June 2001 21:03:20 UTC