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
<[EMAIL PROTECTED]> 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
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
