When trying to delete a contact from a shared ownCloud addressbook, Akonadi believes it is deleted even though the response clearly indicates it is forbidden. Reproducible: Always Steps to Reproduce: Delete a contact from a shared ownCloud addressbook that doesn't have OCP\PERMISSION_DELETE, watch in the access log that the response is a 403. Actual Results: The contact is removed from Akonadi cache. Expected Results: The user should get an appropriate error message. This is against ownCloud master branch, so results may vary. In 4.5 it was possible to delete a resource even though the addressbook only had PERMISSION_UPDATE. Example URL: DELETE /owncloud/remote.php/carddav/addressbooks/test1/contacts_shared_by_test2/C52B52A4-8EA0-0001-2E8C-C89095241A13.vcf Response: HTTP/1.1 403 Forbidden Date: Mon, 26 Nov 2012 20:32:34 GMT Server: Apache/2.2.22 (Ubuntu) (snipped) Content-Length: 602 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/xml; charset=utf-8 Response body: <?xml version="1.0" encoding="utf-8"?> <d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"> <s:exception>Sabre_DAVACL_Exception_NeedPrivileges</s:exception> <s:message>User did not have the required privileges ({DAV:}unbind) for path "addressbooks/test1/contacts_shared_by_test2"</s:message> <s:sabredav-version>1.7.1</s:sabredav-version> <d:need-privileges> <d:resource> <d:href>/owncloud/remote.php/carddav/addressbooks/test1/contacts_shared_by_test2</d:href> <d:privilege> <d:unbind/> </d:privilege> </d:resource> </d:need-privileges> </d:error> I have only tested this with CardDAV, but I suppose the same applies for CalDAV.
He he, just noticed that it doesn't respond on error 500 either, but I found a bug in my code meanwhile ;)
It's weird that you are able to delete in the first place. If the ACLs were applied correctly then you couldn't. Can you have a look at the collection permissions in akonadiconsole?
(In reply to comment #2) > It's weird that you are able to delete in the first place. If the ACLs were > applied correctly then you couldn't. I'm still trying to grasp WebDAV ACLs, so I may have made errors in them :-P >Can you have a look at the collection permissions in akonadiconsole? Right click on collection->Folder properties->ACL, right? Create/Modify/Delete for both collection and items. This is actually not what I assigned to the resource. What is the proper query to retrieve the ACL?
(In reply to comment #3) > >Can you have a look at the collection permissions in akonadiconsole? > > Right click on collection->Folder properties->ACL, right? Exact. > Create/Modify/Delete for both collection and items. This is actually not > what I assigned to the resource. What do you mean by 'assigned to the resource'? From OwnCloud UI? > What is the proper query to retrieve the ACL? The resource uses current-user-privilege-set, as defined in rfc3744. You can check it out here: http://tools.ietf.org/html/rfc3744#page-21 To know what the resource receives you can run a network capture over an unencrypted link and look for the response from the server to this query. If you're fine with posting the response XML please do so, I'll have a look. For the initial issue I'll try to find some time tonight to have a look. The resource should catch the 403.
Created attachment 75505 [details] Result from current-user-privilege-set query I only left results from one contained resource in the collection.
(In reply to comment #4) > What do you mean by 'assigned to the resource'? From OwnCloud UI? Currently from phpmyadmin ;) > If you're fine with posting the response XML please do so, I'll have a look. No problem. It's just test data. The ACL for the collection looks OK to me. It only has write-content permission, but the Akonadi DAV resource apparently interprets that as write including bind and unbind? The bind and unbind on the contained resource is superfluous, but the client should just ignore it as I understand from the RFC https://tools.ietf.org/html/rfc3744#section-3.9 The permissions are checked here btw https://github.com/owncloud/apps/blob/master/contacts/lib/sabre/addressbook.php#L67
Git commit f8105ee3df44b88f371f914de68571e73f736fa1 by Grégory Oestreicher. Committed on 27/11/2012 at 22:53. Pushed by goestreicher into branch 'KDE/4.9'. Always report deletion errors FIXED-IN: 4.9.4 M +4 -15 resources/dav/resource/davgroupwareresource.cpp http://commits.kde.org/kdepim-runtime/f8105ee3df44b88f371f914de68571e73f736fa1
That was fast! Thanks Grégory. Should I file another report regarding not checking for unbind privilege?
(In reply to comment #8) > Should I file another report regarding not checking for unbind privilege? That's up to you, or we can continue in private email. Maybe making this public would help people finding why some servers that used to work suddenly break awfully :)