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

[Julian Reschke <[e-mail]>]

Jari Urpalainen schrieb:
> ...
> 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

Well, if a spec defines a privilege it at least needs to say what it 
means. So can you come up with a definition of that privilege, not in 
terms of method names both describing would kind of resource state 
change it controls?

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

Could you explain how this is a problem of the protocol? As far as I can 
tell, it seems to be an implementation issue, right?

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

Yes.

> 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

It means that only in the case where you don't have an additional 
(custom) privilege preventing this.

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

RFC3744 allows both text/xml and application/xml, and RFC2518bis is 
going to deprecate text/xml (and use application/xml in examples). If we 
ever get to revising RFC3744, we'll make that change as well.

> collations on <principal-property-search> ?, text clarifications, are

I'm not sure that collation support is really important (servers today 
have lots of freedom how to do the property matching, and this IMHO is 
sufficient).

Also, do you have any specific text clarifications in mind?

> users allowed to create groups on-the-fly ? etc. So bis may not be

RF3744 doesn't talk about principal creation at all, I think...

> necessary, but if you (and/or others) have interest to stab on this
> someway, i'm willing to help.

Well, the "current" version is at 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html>,.

But right now, the most important thing the WebDAV WG needs to finish is 
RFC2518bis. Any contributions to that would be even more welcome :-)

Best regards, Julian