Bug 310734 - Akonadi DAV resource doesn't react on 403 errors
Summary: Akonadi DAV resource doesn't react on 403 errors
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: DAV Resource (show other bugs)
Version: 4.9
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-26 21:00 UTC by Thomas Tanghus
Modified: 2012-11-28 08:53 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.4


Attachments
Result from current-user-privilege-set query (1.80 KB, application/xml)
2012-11-27 14:53 UTC, Thomas Tanghus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Tanghus 2012-11-26 21:00:41 UTC
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.
Comment 1 Thomas Tanghus 2012-11-26 21:06:05 UTC
He he, just noticed that it doesn't respond on error 500 either, but I found a bug in my code meanwhile ;)
Comment 2 Grégory Oestreicher 2012-11-27 07:48:22 UTC
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?
Comment 3 Thomas Tanghus 2012-11-27 13:13:56 UTC
(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?
Comment 4 Grégory Oestreicher 2012-11-27 13:36:59 UTC
(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.
Comment 5 Thomas Tanghus 2012-11-27 14:53:58 UTC
Created attachment 75505 [details]
Result from current-user-privilege-set query

I only left results from one contained resource in the collection.
Comment 6 Thomas Tanghus 2012-11-27 15:01:37 UTC
(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
Comment 7 Grégory Oestreicher 2012-11-27 21:54:50 UTC
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
Comment 8 Thomas Tanghus 2012-11-27 22:57:50 UTC
That was fast! Thanks Grégory.
Should I file another report regarding not checking for unbind privilege?
Comment 9 Grégory Oestreicher 2012-11-28 08:53:39 UTC
(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 :)