Re: [ACL] Re: [Ietf-caldav] DAV acls

[Jari Urpalainen <[e-mail]>]

On Fri, 2006-09-22 at 11:24 +0200, ext Julian Reschke wrote:
> Bernard Desruisseaux schrieb:
> > Hi Jari,
> > 
> > I've CCed the WebDAV ACL mailing list ([e-mail]).
> > 
> > See comments below.
> > 
> > Cheers,
> > Bernard
> > 
> > Jari Urpalainen wrote:
> >> Hi all!
> >>
> >> Sorry that my questions/comments are on the wrong list... but caldav
> >> requires dav acls. Anyway, I've been implementing dav acls as an apache
> >> module for a while and there are some issues which are imo worth
> >> discussing (sorry again if these have been discussed before...)
> >>
> >> First, it seems to me that it is impossible to implement a unix sticky
> >> bit  (t) like feature for a collection (like in unix /tmp), i.e. users
> >> could safely create files into a shared collection without the fear that
> >> others can delete them. As it stands now in the spec you'll need to have
> >> <unbind> privilege of the parent collection to remove a file.
> > 
> > This is correct.
> 
> The ACL spec says you need the unbind privilege, but it doesn't say a 
> server can't implement additional (custom) privileges on the member that 
> you would need to have as well.
> 
> >  > So you'll
> >> have to give that privilege to a user for him/her to delete his/her
> >> files. And similarly all other users needs this privilege as well for
> >> their files. So no matter how strict rules you'll have on your files
> >> other users could still remove your files, right ? If I have understood
> >> this correctly, imo it could e.g. be solved by changing the delete rule
> >> so that write privilege for a resource would allow the removal of a
> >> resource (this is actually what i've implemented). I.e. with write
> >> privilege you can "empty" body and dead properties which is almost like
> >> a removal of a resource.
> 
> Yes, you could do that.

right, but doesn't help interop. 

> 
> > You should look at the WebDAV ACL mailing list archive
> > (http://mailman.webdav.org/pipermail/acl/) as well as
> > old versions of the WebDAV ACL draft
> > (http://ietfreport.isoc.org/idref/draft-ietf-webdav-acl/).
> > 
> > You'll notice that up to draft -10 there was a DAV:delete
> > privilege but the WG "couldn't agree for the need of that
> > privilege." Check:
> > 
> > http://mailman.webdav.org/pipermail/acl/2003-November/001782.html
> 
> The problem is that there is no strong definition for DELETE in the 
> first place. Some servers just remove the binding (thus affect the state 
> of the parent collection) and then garbage collect resources with no 
> URIs left, other move them into a trashcan, other destroy them immediately.
> 
> That's why the definition of the DAV:delete privilege was ambiguous and 
> was removed.
> 
hmm. Are we speaking about the spec or actual, maybe somewhat weird
implementations ? Sorry, I'm still confused why e.g. the actual type of
implemented removal will influence delete privilege ? So if you allow
(ambiguous ?) delete you would allow only binding removal, move to
trashcan or complete removal (the latter of which is my preference,
btw.).

> >> Secondly, while distributed acl rules (on different servers) or
> >> referencing distributed group principals may be cool they are quite
> >> challenging to implement, that's why I was hoping to see a postcondition
> >> like "DAV:no-distributed-acls" (and something similar to distributed
> >> groups). Also this should be listed on <acl-restrictions>.  What I mean,
> >> there are other things that are optional to implement which are imo much
> >> easier to implement than these. So probably the "generic"
> >> "no-ace-conflict" could be used here, but it isn't that descriptive for
> >> the client (the implementation of which in general, must be quite
> >> flexible imo btw.).
> 
> When you say "distributed", what exactly are you referring to? The 
> inheritance mechanism defined in 
> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4>?
> 
> > ...

Most likely I've understood (and even implemented) inheritance in this
context (which is imo an "advanced" feature of the spec). What I'm
trying to refer to: if you list e.g. a "remote" principal group uri
(remote.com) within a "local" principal group uri (example.com), i.e.
the acl evaluator should retrieve this remote group content and also
keep sync with this uri content in order to do proper evaluations (and
similarly, when inherited acls exist on another server). So this is imo
hard to implement (DoS, trust=credentials, retrieve, sync, loops etc.),
so I was thinking about simple server implementations which only support
locally accessed rules or groups (and sure you can have multiple virtual
hosts). So having uri references makes things really flexible but also
easily broken. So maybe <recognized-principal> etc. will do the trick,
but I'd prefer to see a clearer alternative (i may have misunderstood
this totally, however...)

> Best regards, Julian

thanks,
Jari