Re: [Ietf-caldav] DAV acls

[Jari Urpalainen <[e-mail]>]

Thanks Bernard for your response,

On Thu, 2006-09-21 at 10:34 -0400, ext Bernard Desruisseaux wrote:
> 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
> 

Well, I would definitely want to have a safe access to resources within
a shared collection. I think that if you really implement this kind of
framework this is one of the basic things (so these acls can't cope even
with "standard" unix filesystem permissions :(). So I'm not happy with
this "safe collection model" only.

> > 
> > 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.
> 
right, from implementers point of view I'll happen to dislike this "most
likely" thing, i.e. I'll prefer explicit behavior especially on security
related matters.  

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

right, makes implementers life easy... Agreed, some umask kind of
feature is definitely on the wish list.
 
>  > 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...
> 
ok, FWIW I think this means either bis (my preference) or possibly you
could write a generic acl extension (even a BCP would help). But anyhow,
imo this concerns all acl usages, not only caldav, at least if you want
to have broader acceptance or deployment of this technology (which is in
general imo pretty reasonable).
thanks,
jari