[ACL] Re: [Ietf-caldav] DAV acls
jari.urpalainen at nokia.com
Mon Sep 25 05:05:03 PDT 2006
On Fri, 2006-09-22 at 20:00 +0200, ext Julian Reschke wrote:
> Jari Urpalainen schrieb:
> > Julian, sorry for being stubborn ;-)
> You aren't.
> > ok, I did some homework about the background:
> > <http://mailman.webdav.org/pipermail/acl/2003-September/001654.html>
> > I think the ambiguity you are referring to is about: when does acls
> > disappear (when there are e.g. several references to single object) ? If
> > they will be unlinked (or really destroyed) during phase 1) I'll agree
> > that there's probably a chance of some weird implications but it depends
> > on the implementation. However, if you do this unlinking on stage 2) I
> > still cannot see what exactly goes wrong. Or you are actually saying
> > that while you implement acls you don't know or don't have control to
> > basic DELETE behavior. Whatever, the issue may have pragmatic
> > implications but it certainly prohibits a useful use-case, imo.
> > anyway, thanks for your enlightenment.
> > br,
> > Jari
> Hm, I'm not sure I follow.
> The ambiguity *I* was mentioning was that RFC2616/RFC2518 do not clearly
> define the semantics of DELETE, thus having a delete privilege makes
> little sense if we can't say what it means.
as an implementer, while I receive a delete request, I am only
interested whether the request is allowed or not, so in principle
request method behavior is of secondary interest. So DELETE may be
ambiguous by rfc2616 terms, but why does <delete> (or similar, i don't
care about the name...) privilege have to be ambiguous, if it just
allows delete request to be performed ? As i tried to explain
previously, you may encounter some unwanted behavior when a resource
(attached with an acl) is being destroyed which at least in my
implementation means also destroying acls (well, i'll store acls within
extended attributes btw.). And if these removals (acl & resource) are
out of sync, definitely there's a chance of getting something wrong, but
it doesn't need to be that way cause implementers should know ;-) what's
> What we did agree upon is that you can't DELETE something unless you
> have a unbind permission on the parent collection. That's a well-defined
Well defined, right and yes, a useful privilege. The problem is, that it
can be too powerful for shared collections, so if e.g. two users (or
groups), a) & b) are allowed to create resources onto the same shared
collection (so a) & b) have <bind> privilege there) and if i want them
to also remove the resources they have created I must allow <unbind> to
this shared collection. But then assume that a) & b) set strict acls for
these new resources ("private"). Well, an a) user may not even read b)'s
resources but it can unbind b)'s resources (which means usually unlink
in unix terms) ! When I started the module implementation, I took it for
granted that rfc3744 had this basic unix sticky bit (t) like feature so
that different users can't step onto the toes of others. So you can
overcome this by only allowing collections by a group/user basis but I
find this too limiting, given the fact that there's a relatively easy
solution for this, imo (although we seem to be disagreeing here).
> Now whether you need *more* than that privilege depends entirely on what
> the server does after removing the binding (nothing/move to
> trashcan/destroy object/whatever). The base spec just doesn't tell us.
> Thus, the ACL spec is silent on that.
> *If* a server requires additional privileges, it can add a custom
> privilege that a client can discover. However, that privilege wouldn't
> have shown up in the method table in
> <http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>, because
> by definition it wouldn't have been a *required* privilege.
> That being said, if you feel that the absence of something like
> DAV:destroy-resource is a problem, there's always the possibility to
> describe it in a separate document, and try to get implementors that
> have a matching resource deletion model to support this...
> Best regards, Julian
Yes, I would actually want to have this feature (in addition to e.g. a
user settable default acl == ~ unix umask). But how this would work
within an extension, i don't know. The spec already requires/implies to
quite many negotiations, so client implementations aren't that trivial
mostly because servers may be so flexible. Secondly, there could be some
clarifications on rfc3744: application/xml mime type on examples,
collations on <principal-property-search> ?, text clarifications, are
users allowed to create groups on-the-fly ? etc. So bis may not be
necessary, but if you (and/or others) have interest to stab on this
someway, i'm willing to help.
More information about the Ietf-caldav