Bug#774130: cyrus-caldav: [PATCH] dav: Fails when multiple accounts accessing private calendars from same client

[Daniel Dickinson]

Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch

Due to strict interpretation/implementation of HTTP Auth RFC having private calendars
from multiple accounts accessed by the same instance of a client (e.g. Icedove) fails
with "403 Forbidden" for any accounts accessed after the first.

This issue is why Mozilla added the about:config option calendars.network.multirealm
option (which apparently is also apparently iCal's default behavior).

In short it is required to have HTTP Auth occur for different URI's not just different
server names because calendars are not differentied by server name but instead by
URI.

This attached patch is a hack that that re-requests HTTP Auth if the current http userid
does not match the userid in the calender URI and HTTP header does not have a an
Authorization field.


Description: Fix CalDAV/CardDAV for multiple user's calendars from same client
   Workaround for accessing different users' collections on the same server
   with same hostname.  Without this fix, this fails because HTTP auth is
   only done once.  This is the same issue that had Mozilla Lightning add
   the calendar.network.multream option.
   Basically interpretation of RFC's such that HTTP Auth is only done once
   hostname:port reqardless of the URI causes CalDAV/CardDAV to fail when
   one does not have a unique hostname:port per user and access to multiple
   users' calendars is done from the same client, unless one opens up the
   ACLS so that the calendars are all accessible from a single user (in
   addition to the owner of the calendar)
   This workaround forces an authentication request if the userid does not
   match the user portion of the calendar/addressbook URI.  It does require
   that the client know enough to not use the same authorization for the
   different calenders (e.g. Mozilla Lightning with multirealm enabled
   or, apparently, iCal)

Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
===================================================================
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/httpd.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
@@ -919,6 +919,9 @@ static void cmdloop(void)
 	const struct namespace_t *namespace;
 	const struct method_t *meth_t;
 	struct request_line_t *req_line = &txn.req_line;
+        char collection_userid[MAX_MAILBOX_BUFFER];
+        char *user_loc;
+	int has_authorization = 0;
 
 	/* Reset txn state */
 	txn.meth = METH_UNKNOWN;
@@ -1200,6 +1203,7 @@ static void cmdloop(void)
 
 	/* Perform authentication, if necessary */
 	if ((hdr = spool_getheader(txn.req_hdrs, "Authorization"))) {
+	    has_authorization = 1;
 	    if (httpd_userid) {
 		/* Reauth - reinitialize */
 		syslog(LOG_DEBUG, "reauth - reinit");
@@ -1244,6 +1248,33 @@ static void cmdloop(void)
 	    }
 	}
 
+	/* Workaround for accessing different users' collections on the same server
+           with same hostname.  Without this fix, this fails because HTTP auth is
+           only done once.  This is the same issue that had Mozilla Lightning add
+           the calendar.network.multream option.
+           Basically interpretation of RFC's such that HTTP Auth is only done once
+           hostname:port reqardless of the URI causes CalDAV/CardDAV to fail when
+           one does not have a unique hostname:port per user and access to multiple
+           users' calendars is done from the same client, unless one opens up the
+           ACLS so that the calendars are all accessible from a single user (in
+           addition to the owner of the calendar)
+           This workaround forces an authentication request if the userid does not
+           match the user portion of the calendar/addressbook URI.  It does require
+           that the client know enough to not use the same authorization for the
+           different calenders (e.g. Mozilla Lightning with multirealm enabled
+           or, apparently, iCal)
+        */
+	if (!has_authorization && httpd_userid) {
+	    user_loc = strstr(txn.req_uri->path, "/user/");
+	    if (user_loc != NULL) {
+	        user_loc += 6;
+	        strlcpy(collection_userid, user_loc, strcspn(user_loc, "/"));
+	        if (strcmp(collection_userid, httpd_userid)) {
+		    *httpd_userid = 0;
+               } 
+	    }
+       }	
+           
 	/* Request authentication, if necessary */
 	switch (txn.meth) {
 	case METH_GET:

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cyrus-caldav depends on:
ii  cyrus-common  2.4.17+caldav~beta10-13~dfd2
ii  dpkg          1.17.22
ii  libc6         2.19-13
ii  libcomerr2    1.42.12-1
ii  libdb5.3      5.3.28-7~deb8u1
ii  libical1      1.0-1.1
ii  libkrb5-3     1.12.1+dfsg-16
ii  libsasl2-2    2.1.26.dfsg1-12
ii  libsqlite3-0  3.8.7.1-1
ii  libssl1.0.0   1.0.1j-1
ii  libwrap0      7.6.q-25
ii  libxml2       2.9.1+dfsg1-4
ii  zlib1g        1:1.2.8.dfsg-2+b1

cyrus-caldav recommends no packages.

cyrus-caldav suggests no packages.

-- no debconf information