2051561 - CalDAV: read-only shared calendar (server grants only DAV:write-properties) is treated as writable

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[ndo84bw]

Steps to reproduce:

1. On a CalDAV server (e.g. Nextcloud), share a calendar with another user with read-only rights.
2. In Thunderbird, subscribe to that shared calendar as the read-only user.
3. Try to create an event in the shared calendar.

Actual results:

The server rejects the write with HTTP 404 (or 403), because the user has no permission to write to that calendar. Thunderbird had treated the shared calendar as writable, so it lets the user try, and the failure surfaces as a generic error the user cannot act on (NS_ERROR_FAILURE / 0x80004005).

Root cause: Thunderbird reads write permission from the WebDAV current-user-privilege-set (RFC 3744), but the check counts DAV:write-properties as a write privilege:

this.readOnly = !["D:write", "D:write-content", "D:write-properties", "D:all"].some(priv => privs.has(priv));

The same check exists in three places (CalDavCalendar, plus the CalDavProvider and CalICSProvider autodiscovery) and was introduced in bug 1665203.

Expected results:

Thunderbird should read the write permission the server reports and, when no write privilege is present, mark the calendar read-only - both at set-up and on every restart.

Here the server reports only read, read-acl and write-properties. Per RFC 3744, write-properties only allows changing the collection's own WebDAV properties via PROPPATCH (e.g. display name, colour); it does not allow creating or modifying events. Creating an event needs DAV:bind, modifying one needs DAV:write-content (or the aggregates DAV:write / DAV:all). So write-properties is not a reason to keep the calendar writable.

Marking such calendars read-only also fixes follow-on problems:

• Accepting a meeting invitation sent to the user no longer writes the update into the wrong (read-only) calendar just because that calendar already holds an event with the same UID; the write goes to a writable calendar instead.
• The user no longer gets the cryptic 0x80004005 failure they cannot interpret.

Comment 1

[ndo84bw]

Attachment: Bug 2051561 - Don't treat DAV:write-properties as write access for CalDAV calendars. r=darktrojan

Per RFC 3744, DAV:write-properties only authorizes PROPPATCH on a
resource's own properties, not creating or modifying calendar object
resources. Servers grant it on read-only shares (e.g. Nextcloud grants
{read, read-acl, write-properties}), so counting it as a write privilege
wrongly marks a read-only share as writable. Invitation accepts then PUT
to it and fail with 404.

Remove DAV:write-properties from the writable-privilege list and add
DAV:bind (the privilege that permits creating a new resource via PUT), in
the three sites that derive read-only from current-user-privilege-set:
CalDavCalendar, CalDavProvider and CalICSProvider. Add regression tests
for the privilege-set interpretation.

Comment 2

[Magnus Melin [:mkmelin] (away until Aug 10)]

If the patch is ready to land, please set the checkin-needed-tb keyword on the bug and someone will land it shortly

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/12fa0b523ac3
Don't treat DAV:write-properties as write access for CalDAV calendars. r=darktrojan