[CalendarServer-users] Client library and admin tool

[Scott Buchanan]

I'm trying to work with the acl's with runshell.py and I think there  
may be issues with runshell.py.  I'm trying to do something simple and  
it makes the calendar on which I'm making changes inaccessible.

First, my setup.

- server = 10.4.11 server version
- CalServer = 1.3 branch r2260
- CalDAVClientLibrary 2254

I'm working with OD on the server.  Everything starts up and works  
fine.  For now I've added a user - mainconf - to work as the calendar  
for our main conference room.   After startup everything is fine.   
User mainconf can access the calendar and all other users (members of  
same group as mainconf) can subscribe to the calendar.  I'm just using  
10.5 iCal for access, along with a browser and runshell.py.  Access  
results are consistent across all of these.

Now I use runshell.py to try and add write access to mainconf's  
calendar for myself - scott.  Below is the session.  The problems are  
as follows.

1) I've tried to ask runshell.py to add the write access for myself as  
both before 1  and 2 current ACL's.  In both cases it was added as the  
last ACL

2) After this action I can no longer access the calendar, by any  
method, as the original user - mainconf - or myself - scott

3) After using acl -i in runshell.py to remove ACL 6 item 2 above is  
still the case.

I don't know if this is the place to put this information or if I  
should file a ticket?

Thanks,


/calendars/users/mainconf > acl -i
Entering ACL edit mode on resource: /calendars/users/mainconf/
ACL > add

  1. Principal: AUTHENTICATED
     Grant: {DAV:}read

  2. Principal: Main Conference Room (URL: /principals/__uids__/ 
C48BC80E-9483-4164-9A30-011BB64D4FB0/)
     Status: PROTECTED
     Grant: {DAV:}all

  3. Principal: AUTHENTICATED
     Grant: {urn:ietf:params:xml:ns:caldav}read-free-busy

  4. Principal: Main Conference Room#calendar-proxy-read (URL: / 
principals/__uids__/C48BC80E-9483-4164-9A30-011BB64D4FB0/calendar- 
proxy-read/)
     Status: PROTECTED
     Grant: {DAV:}read

  5. Principal: Main Conference Room#calendar-proxy-write (URL: / 
principals/__uids__/C48BC80E-9483-4164-9A30-011BB64D4FB0/calendar- 
proxy-write/)
     Status: PROTECTED
     Grant: {DAV:}read, {DAV:}write

Add ACL before [1 - 6] or cancel [q]: 1
Principal Type:
   1. Principal path
   2. All
   3. Authenticated
   4. Unauthenticated
   5. Property
Select type: 1
Enter principal path: /principals/users/scott
Invert principal [y/n]: n
Grant or Deny privileges [g/d]: g
Privileges:
   a. {DAV}read
   b. {DAV}write
   c. {DAV}write-properties
   d. {DAV}write-content
   e. {DAV}read-acl
   f. {DAV}read-current-user-privilege-set
   g. {DAV}write-acl
   h. {DAV}bind
   i. {DAV}unbind
   j. {DAV}all
   k. {CALDAV}read-free-busy
   l. {CALDAV}schedule
   q. quit without changes
Select multiple items: b
ACL > list

  1. Principal: AUTHENTICATED
     Grant: {DAV:}read

  2. Principal: Main Conference Room (URL: /principals/__uids__/ 
C48BC80E-9483-4164-9A30-011BB64D4FB0/)
     Status: PROTECTED
     Grant: {DAV:}all

  3. Principal: AUTHENTICATED
     Grant: {urn:ietf:params:xml:ns:caldav}read-free-busy

  4. Principal: Main Conference Room#calendar-proxy-read (URL: / 
principals/__uids__/C48BC80E-9483-4164-9A30-011BB64D4FB0/calendar- 
proxy-read/)
     Status: PROTECTED
     Grant: {DAV:}read

  5. Principal: Main Conference Room#calendar-proxy-write (URL: / 
principals/__uids__/C48BC80E-9483-4164-9A30-011BB64D4FB0/calendar- 
proxy-write/)
     Status: PROTECTED
     Grant: {DAV:}read, {DAV:}write

  6. Principal: Scott Buchanan (URL: /principals/__uids__/D594F48B- 
DD83-48A5-9679-4989FA4CC6F7/)
     Grant: {DAV:}write
On Apr 4, 2008, at 9:26 AM, Cyrus Daboo wrote:

> Hi Scott,
>
> --On April 4, 2008 8:19:03 AM -0700 Scott Buchanan  
> <dscottbuch at mac.com> wrote:
>
>> is the following consistent with your analysis?
>>
>> HTTP/1.1 403 Forbidden
>> Date: Fri, 04 Apr 2008 15:17:32 GMT
>> DAV: 1, access-control, calendar-access, calendar-schedule,
>> calendar-availability, inbox-availability, calendar-proxy,
>> calendarserver-private-events
>> Content-Type: text/xml
>> Content-Length: 104
>> Server: Twisted/2.5.0 TwistedWeb/[twisted.web2, version 0.2.0]
>> TwistedCalDAV/1.3-dev (r2269)
>> <?xml version='1.0' encoding='UTF-8'?>
>> <error xmlns='DAV:'>
>>   <no-protected-ace-conflict/>
>> </error>
>>
>>
>> If so, I understand you suggestions but it seems overly complex.   
>> Is this
>> how it is handled on Leopard Server, thru OD and the GUi that comes  
>> with
>> that?
>
> Yes '<no-protected-ace-conflict/>' is what I was describing.
>
> NB There is another approach to this by using proxy. Here is how  
> this would work:
>
> 1) Instead of creating a group calendar, create a regular user to  
> represent the group.
> 2) Use that user's credentials to login and manage the calendars  
> (create/delete).
> 3) Assign other users as read-only or read-write proxies for that  
> user (the runshell proxies command easily manages that).
>
> A slight variation of this is to assign a group principal as a proxy  
> to a user. Then you can manage the proxies by adding individual  
> users to the group rather than directly using the proxy command.
>
> I think this is probably a better bet than managing the ACLs directly.
>
> There has been a fair amount of discussion in the Calendaring and  
> Scheduling Consortium by caldav-related folks about defining a more  
> generic proxy scheme than we have in our server. The primary goal of  
> this is to avoid admins, clients etc ever having to manipulate ACLs  
> directly, because, frankly, WebDAV ACLs are overly complex for most  
> of the operations people want to do. The goal would be to have the  
> server provision all the required types of ACLs and then use group  
> membership as a way of giving particular users the appropriate  
> rights. That is basically what the current proxy mechanism does.
>
> -- 
> Cyrus Daboo
>