Re: [Ietf-caldav] DAV acls

[Bernard Desruisseaux <[e-mail]>]

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.

 > 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.

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

> 
> 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.).
> 
> Still a question about acl usage with caldav: a client puts a new ics
> file into a calendar collection and server does not (auto)generate any
> acl for it (this is very implementation specific if/as we follow
> rfc3744).

Actually, a server most likely will set a default ACL on the new
resource.

> The client does not support acls (uses only "private"
> calendars). So another client queries freebusy info, is it allowed or
> not ? (probably latter).

All depends on the default ACL set by the server. Currently, I would
expect servers to allow users to configure the default ACL value in
a proprietary way.

 > But agreed, this ambiguity results from rfc3744
> being "liberal". So imo, it would be clearer if servers must generate
> e.g. an acl where the owner has full rights (and others none) for a new
> created resource. In addition, acls would then be needed for truly
> shared resources only (or allowing freebusy reports for others).

Correct. Servers have no standard way to allow client to manage or
discover the default/initial ACL value for new resources.

Cyrus, Lisa and I had lots of discussions on whether a calendar
collection should have a property (protected or not) that would
allow client to discover and manage (if the property is not
protected) the default ACL for new calendar object resources.
We also had discussions on ACL inheritance as well. As you may
have guessed, we have decided to address those issues in a
separate draft...

> 
> There are quite many other minor issues as well (or difficulties to
> understand the meaning of the spec) but in general I like the basic
> simplicity of the spec. But I'll hope someone can enlighten me first
> with answers to these basic questions...
> 
> thanks,
> Jari
> 
> _______________________________________________
> Ietf-caldav mailing list -- [e-mail]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav