This happens on the current PEAR version, too:

webmail                      5.2.12  stable
kronolith                    4.2.13  stable
Horde_Dav                    1.1.2   stable

I think, Horde maps the permission to CalDAV privileges wrongly. They 
seem to be the same for all calendars no matter what permissions are 
set in the GUI.

I think also, that CalDAV returns HTTP 500, too often. Instead it 
should use HTTP 4xx. Maybe, some clients try to modify the ressoures 
only, because the reported privileges are wrong.

Also, IMHO, Horde should not give any other user than the calendar 
owner access permission to the calendar in comment 7.

We have a ReadOnly Calendar shared to all, see attachement.

CalDAV returns these privileges, which matches those of the calendar 
in comment #7 _and_ matches those privileges of the user's own calendar.

         <d:propstat>
             <d:prop>
                 <d:current-user-privilege-set>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-free-busy 
xmlns:d="urn:ietf:params:xml:ns:caldav"/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-acl/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-properties/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-content/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:bind/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:unbind/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:unlock/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-acl/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-current-user-privilege-set/>
                     </d:privilege>
                 </d:current-user-privilege-set>

If I put a new event into this calendar, I get:

HTTP/1.1 500 Internal Server Error

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
   <s:exception>Sabre\DAV\Exception</s:exception>
   <s:message>Calendar does not exist or no permission to edit</s:message>
   <s:sabredav-version>1.8.10</s:sabredav-version>
</d:error>

Well, the user does not have no permission in Horde, but CalDAV claimed so.

If I emit the request with the user's calendar URL, the request succeeds.

Let me restart.

I create with user dvtes1 a new calendar and share it like the 
attachement shows.

This calendar shows up for user dvtest2 in the GUI and in CalDAV I get 
this response for querying calendars:

     <d:response>
         
<d:href>/horde/rpc.php/calendars/dvtest2/calendar~c6rKd7q_99wt7vMg5tAKwt3/</d:href>
         <d:propstat>
             <d:prop>
                 <d:current-user-privilege-set>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-free-busy 
xmlns:d="urn:ietf:params:xml:ns:caldav"/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-acl/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-properties/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:write-content/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:bind/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:unbind/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:unlock/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-acl/>
                     </d:privilege>
                     <d:privilege xmlns:d="DAV:">
                         <d:read-current-user-privilege-set/>
                     </d:privilege>
                 </d:current-user-privilege-set>
                 <d:displayname>dv1/shared 
[dvtest1]</d:displayname><x5:calendar-color 
xmlns:x5="http://apple.com/ns/ical/">#5c31dfff</x5:calendar-color>
                 <cal:supported-calendar-component-set>
                     <cal:comp name="VEVENT"/>
                 </cal:supported-calendar-component-set>
                 <d:resourcetype>
                     <d:collection/><cal:calendar/>
                 </d:resourcetype>
             </d:prop>
             <d:status>HTTP/1.1 200 OK</d:status>
         </d:propstat>
     </d:response>

When I now request some data from this calendar with:

REPORT 
/horde/rpc.php/calendars/dvtest2/calendar~c6rKd7q_99wt7vMg5tAKwt3/ 
HTTP/1.1
Host: 10.***
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, 
like Gecko) akonadi_davgroupware_resource_62/4.14.2 Safari/534.34
Pragma: no-cache
Cache-control: no-cache
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, 
image/*;q=0.9, */*;q=0.8
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,en;q=0.9
Content-Type: text/xml
Depth: 2
Authorization: ****
Content-Length: 825

<?xml version="1.0" encoding="utf-8"?>
<C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
<C:calendar-data>
  <C:comp name="VCALENDAR">
    <C:prop name="VERSION"/>
    <C:comp name="VEVENT">
      <C:prop name="SUMMARY"/>
      <C:prop name="UID"/>
      <C:prop name="DTSTART"/>
      <C:prop name="DTEND"/>
      <C:prop name="DURATION"/>
      <C:prop name="RRULE"/>
      <C:prop name="RDATE"/>
      <C:prop name="EXRULE"/>
      <C:prop name="EXDATE"/>
      <C:prop name="RECURRENCE-ID"/>
    </C:comp>
    <C:comp name="VTIMEZONE"/>
  </C:comp>
</C:calendar-data>
</D:prop>
<C:filter>
<C:comp-filter name="VCALENDAR">
  <C:comp-filter name="VEVENT">
    <C:time-range start="20140104T000000Z"
                  end="20160105T000000Z"/>
  </C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>


Horde responses with:

HTTP/1.1 500 Internal Server Error
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
     <s:exception>Sabre\DAV\Exception</s:exception>
     <s:message>Calendar does not exist or no permission to edit</s:message>
     <s:sabredav-version>1.8.10</s:sabredav-version>
</d:error>

If I instead use
REPORT calendar_i_have_ReadOnly_access_to ?
?

I get a multi status OK and VEVENTs.

The former is correct, the latter not. Make sure you copy the URL when 
logged in as dvtest2. The users have different URLs for the same 
calendar.
Is the latter URL the one that throws the 500 with the error message 
you posted? That would be expected behavior.

That would be a correct URL. Does this request generate the same error 
in the logs?
They does, usually.

Not a 404 but not a 500 either. Again, is this the same error message 
in the logs?

When I use a working calendar with cadaver, I see plenty of ics files. 
When I use this shard calendar, I get a 500 HTTP error.
Well, I re-tested. It is possible that last time I used an existing 
calendar _and_ I used the URL of one user with another user's 
credential.

I now have this calendar 
https://127.0.0.1:1443/horde/rpc.php/calendars/dvtest1/calendar~c6rKd7q_99wt7vMg5tAKwt3/ of user dvtest1 showing up as https://127.0.0.1:1443/horde/rpc.php/calendars/dvtest1/calendar~c6rKd7q_99wt7vMg5tAKwt3/ for user 
dvtest2.

These URLs are visible in the GUI of
kronolith                    4.2.11  stable
webmail                      5.2.11  stable
. Apple iCal does automatically discover the calendar for dvtest2. 
However, on access this URL I get:

  "PROPFIND 
/horde/rpc.php/calendars/dvtest2/calendar~c6rKd7q_99wt7vMg5tAKwt3/ 
HTTP/1.1" 500 1018 "-" "Mac_OS_X/10.9.5 (13F1603) CalendarAgent/176.2"

IMHO, a calendar a user has no permission to should not be discovered.
If the permissions of "Object Creator" may mean that any user has 
access to the calendar, that all users should be able to query 
(select) the calendar.

On the other hand, shouldn't the client get a 4xx code, probably 404 
for calendars the user has no permission to?

=====

This problem has a general nature probably. One calendar is from 
dvtest1 to dvtest2 as read only, (Show and Read).  iCal tries to 
update the "acknowledged" status to Horde, but Horde returns 500 as 
well.

"PUT 
/horde/rpc.php/calendars/dvtest2/calendar~n6rEEYYc_Nwej1GIqtXcSck/zgcoDob0mEmtMib3PzVM7Wp.ics HTTP/1.1" 500 2323 "-" "Mac_OS_X/10.9.5 (13F1603) 
CalendarAgent/176.2"

Shouldn't this a 404 as well?

First of all, this is a CalDAV URL and not a valid WebDAV URL. And 
then it's exactly what happens if you still use an incorrect CalDAV 
URL from Kronolith versions earlier than 4.2.3. Are you sure this URL 
is from a recent Kronolith version?

I have setup a PEAR installation:

kronolith                    4.2.11  stable
webmail                      5.2.11  stable

created a 2nd calendar of an user, ticked all permissions for Object 
Creator, but nothing else and tried to access it with a webdav client:

  cadaver 
'https://127.0.0.1:443/horde/rpc.php/calendars/dvtest1/calendar~K-O2F29fNvZNnvyNhStU_w1/'

Message from syslogd@msaj at Jan 27 20:54:32 ...
  HORDE: [kronolith] Call to a member function toHash() on boolean 
[pid 11253 on line 686 of 
"/var/www/horde/kronolith/lib/Application.php"]

Broadcast message from systemd-journald@msaj (Wed 2016-01-27 20:54:32 CET):

HORDE[11253]: [kronolith] Call to a member function toHash() on 
boolean [pid 11253 on line 686 of 
"/var/www/horde/kronolith/lib/Application.php"]

Could not open collection:
500 Internal Server Error

Is this still happening?

On the Webpage an user has one own and four shared calendars and the 
user's tasks. I see the data (pencil icon) of all calendars except 
one. The latter shows "You are not allowed to see this calendar."   A 
CalDAV client queries the principal of an user and gets 6 shares, all 
prefixes by <URL>rpc.php/calendars/<user>/

calendar:1
calendar:2
calendar:3
calendar~4
calendar~5
tasks~6

Calemdars 1 and 2 are public ones, 3 and 5 and shared ones from 
another user, 4 and 6 are ones from the user itself.

All calendars except 5 are working as expected. The requests to 
calendar 5 result in "500 Internal server error". A webdav client 
shows the same.

The calendar 5 has been accidently shared as "Object Creator         x Show 
        x Read         x Edit         x Delete", everything else is unchecked, no user 
configuered.

The annoying thing here is the 500 http error code for the CalDAV 
client, because it displays a warning each retry time. IMHO, if the 
calendar is shared and visible to the user, the user should get access 
to its metadata / container / whatever, but not necessarily to the 
events, hence, neither the GUI nor CalDAV should get an error.

Maybe related to bug #12380 .