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

Julian Reschke <julian.reschke@gmx.de> Fri, 22 September 2006 09:24 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf-caldav@osafoundation.org
Delivered-To: ietf-caldav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B19FE7FDB4 for <ietf-caldav@osafoundation.org>; Fri, 22 Sep 2006 02:24:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A35BD142267 for <ietf-caldav@osafoundation.org>; Fri, 22 Sep 2006 02:24:00 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25915-01 for <ietf-caldav@osafoundation.org>; Fri, 22 Sep 2006 02:23:58 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 569B0142260 for <ietf-caldav@osafoundation.org>; Fri, 22 Sep 2006 02:23:58 -0700 (PDT)
Received: (qmail invoked by alias); 22 Sep 2006 09:23:57 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 22 Sep 2006 11:23:57 +0200
X-Authenticated: #1915285
Message-ID: <4513ABB2.8050208@gmx.de>
Date: Fri, 22 Sep 2006 11:24:02 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
Subject: Re: [ACL] Re: [Ietf-caldav] DAV acls
References: <1158841595.2566.129.camel@esdhcp038148.research.nokia.com> <4512A305.4050501@oracle.com>
In-Reply-To: <4512A305.4050501@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL
X-Spam-Level:
Cc: CalDAV DevList <ietf-caldav@osafoundation.org>, acl@webdav.org
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Sep 2006 09:24:00 -0000

Bernard Desruisseaux schrieb:
> Hi Jari,
> 
> I've CCed the WebDAV ACL mailing list (acl@webdav.org).
> 
> 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.

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

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

> ...

Best regards, Julian