Errors with group based access control
This happens when I try to "get details" in Mulberry on a group's directory, no matter whether I am a member of that group or not. (I am using the XML directory backend as long as I don't know how to use LDAP.) 2006/12/14 13:51 +0200 [HTTPChannel,33,134.169.34.51] PROPFIND /calendars/group/cipusers/ HTTP/1.1 2006/12/14 13:51 +0200 [-] "Error reading property ('DAV:', 'current-user-privilege-set') for resource /calendars/group/cipusers/: ('<', 'S', 't', 'a', 't', 'u', 's', 'R', 'e', 's', 'p', 'o', 'n', 's', 'e', ' ', '4', '0', '1', ' ', 'A', 'c', 'c', 'e', 's', 's', ' ', 'd', 'e', 'n', 'i', 'e', 'd', ' ', 'w', 'h', 'i', 'l', 'e', ' ', 'r', 'e', 'a', 'd', 'i', 'n', 'g', ' ', 'p', 'r', 'o', 'p', 'e', 'r', 't', 'y', ' ', '{', 'D', 'A', 'V', ':', '}', 'c', 'u', 'r', 'r', 'e', 'n', 't', '-', 'u', 's', 'e', 'r', '-', 'p', 'r', 'i', 'v', 'i', 'l', 'e', 'g', 'e', '-', 's', 'e', 't', '.', '>')" 2006/12/14 13:51 +0200 [-] 401 response while getting property: ('DAV:', 'current-user-privilege-set') 2006/12/14 13:51 +0200 [HTTPChannel,34,134.169.34.51] PROPFIND /calendars/group/cipusers/ HTTP/1.1 2006/12/14 13:51 +0200 [-] "Error reading property ('DAV:', 'acl') for resource /calendars/group/cipusers/: ('<', 'S', 't', 'a', 't', 'u', 's', 'R', 'e', 's', 'p', 'o', 'n', 's', 'e', ' ', '4', '0', '1', ' ', 'A', 'c', 'c', 'e', 's', 's', ' ', 'd', 'e', 'n', 'i', 'e', 'd', ' ', 'w', 'h', 'i', 'l', 'e', ' ', 'r', 'e', 'a', 'd', 'i', 'n', 'g', ' ', 'p', 'r', 'o', 'p', 'e', 'r', 't', 'y', ' ', '{', 'D', 'A', 'V', ':', '}', 'a', 'c', 'l', '.', '>')" 2006/12/14 13:51 +0200 [-] 401 response while getting property: ('DAV:', 'acl')
On Thu, December 14, 2006 8:09 am, Frank Strauß wrote:
This happens when I try to "get details" in Mulberry on a group's directory, no matter whether I am a member of that group or not. (I am using the XML directory backend as long as I don't know how to use LDAP.)
No idea on the get details issue, but as soon as I get my lab set back up after my move I plan to evaluate the new trunk and then write my article on LDAP integration. The only bit that wasn't working for me was kerb, which I realized doesn't matter as I haven't seen any kerberized caldav clients to use. :) The basics are... 1. Extend your schema to add a calendar principal attribute. 2. Rebuild and install PyOpenDirectory with your custom attribute. Josh -- Josh Wisenbaker U, U, D, D, L, R, L, R, B, A, Start for your server http://www.afp548.com
Josh Wisenbaker wrote:
On Thu, December 14, 2006 8:09 am, Frank Strauß wrote:
This happens when I try to "get details" in Mulberry on a group's directory, no matter whether I am a member of that group or not. (I am using the XML directory backend as long as I don't know how to use LDAP.)
No idea on the get details issue, but as soon as I get my lab set back up after my move I plan to evaluate the new trunk and then write my article on LDAP integration.
The only bit that wasn't working for me was kerb, which I realized doesn't matter as I haven't seen any kerberized caldav clients to use. :)
The basics are...
1. Extend your schema to add a calendar principal attribute. 2. Rebuild and install PyOpenDirectory with your custom attribute.
Thanks, Josh! You motivate me to give it another try... :-) But I have some further questions: Where did you take the OID 1.3.6.1.4.1.63.1001.1.1.1.1.99 from? Is it kind of official? Does it matter in any way which OID we use (as long as we are testing it in our own environments)? What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"? I'm no Python guru. Do you know how this warning can be avoided? Probably at some place, my Tiger Python-2.3 stuff is used, although 2.5 is available and the first in my $PATH. 2006/12/14 15:49 +0200 [-] /private/var/automount/home/strauss/Developer/CalendarServer/twistedcaldav/directory/appleopendirectory.py:30: exceptions.RuntimeWarning: Python C API version mismatch for module opendirectory: This Python has API version 1013, module opendirectory has version 1012.
Frank Strauß wrote:
I'm no Python guru. Do you know how this warning can be avoided? Probably at some place, my Tiger Python-2.3 stuff is used, although 2.5 is available and the first in my $PATH.
2006/12/14 15:49 +0200 [-] /private/var/automount/home/strauss/Developer/CalendarServer/twistedcaldav/directory/appleopendirectory.py:30: exceptions.RuntimeWarning: Python C API version mismatch for module opendirectory: This Python has API version 1013, module opendirectory has version 1012.
I found the reason for this. Maybe others like to know it... When things are built by "./run -s", the setup system makes the compiler be called with something like "-isysroot /Developer/SDKs/MacOSX10.4u.sdk". This path is used to find the headers that are used to build opendirectory.so. When you install a newer Python, e.g. 2.5, the stuff in /Library/Frameworks/Python.framework is updated, but not the stuff in /Developer/... I helped myself by the following symlinks, but I cannot guarantee that it won't break any future Python upgrades or other development projects. # ls -l /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Python.framework/Versions total 24 drwxr-xr-x 5 root wheel 170 Dec 7 16:11 2.3 lrwxr-xr-x 1 root wheel 49 Dec 14 16:49 2.5 -> /Library/Frameworks/Python.framework/Versions/2.5 lrwxr-xr-x 1 root wheel 3 Dec 14 16:49 Current -> 2.5 lrwxr-xr-x 1 root wheel 3 Dec 7 16:11 Current.old -> 2.3
Huh. I don't know where the -isysroot is coming from; I can't find the string 'sysroot' in our source tree... -wsv On Dec 14, 2006, at 7:57 AM, Frank Strauß wrote:
Frank Strauß wrote:
I'm no Python guru. Do you know how this warning can be avoided? Probably at some place, my Tiger Python-2.3 stuff is used, although 2.5 is available and the first in my $PATH. 2006/12/14 15:49 +0200 [-] /private/var/automount/home/strauss/ Developer/CalendarServer/twistedcaldav/directory/ appleopendirectory.py:30: exceptions.RuntimeWarning: Python C API version mismatch for module opendirectory: This Python has API version 1013, module opendirectory has version 1012.
I found the reason for this. Maybe others like to know it...
When things are built by "./run -s", the setup system makes the compiler be called with something like "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk". This path is used to find the headers that are used to build opendirectory.so. When you install a newer Python, e.g. 2.5, the stuff in /Library/Frameworks/Python.framework is updated, but not the stuff in /Developer/... I helped myself by the following symlinks, but I cannot guarantee that it won't break any future Python upgrades or other development projects.
# ls -l /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ Python.framework/Versions total 24 drwxr-xr-x 5 root wheel 170 Dec 7 16:11 2.3 lrwxr-xr-x 1 root wheel 49 Dec 14 16:49 2.5 -> /Library/ Frameworks/Python.framework/Versions/2.5 lrwxr-xr-x 1 root wheel 3 Dec 14 16:49 Current -> 2.5 lrwxr-xr-x 1 root wheel 3 Dec 7 16:11 Current.old -> 2.3
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
On Thu, December 14, 2006 9:00 am, Frank Strauß wrote:
Josh Wisenbaker wrote:
On Thu, December 14, 2006 8:09 am, Frank Strauß wrote:
This happens when I try to "get details" in Mulberry on a group's directory, no matter whether I am a member of that group or not. (I am using the XML directory backend as long as I don't know how to use LDAP.)
No idea on the get details issue, but as soon as I get my lab set back up after my move I plan to evaluate the new trunk and then write my article on LDAP integration.
The only bit that wasn't working for me was kerb, which I realized doesn't matter as I haven't seen any kerberized caldav clients to use. :)
The basics are...
1. Extend your schema to add a calendar principal attribute. 2. Rebuild and install PyOpenDirectory with your custom attribute.
Thanks, Josh!
You motivate me to give it another try... :-) But I have some further questions:
Where did you take the OID 1.3.6.1.4.1.63.1001.1.1.1.1.99 from? Is it kind of official? Does it matter in any way which OID we use (as long as we are testing it in our own environments)?
That's based on Apple's assignment. The "1.3.6.1.4.1" means private enterprise and the "63" means Apple. I've submitted a request to IANA for a AFP548.com number to use. I suppose it really doesn't matter as long as Apple never conflicted anything with it.
What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"?
The FQDN of the principal. "https://test.afp548.com:8443/principals/user/josh" I was planning on doing a script or dsimport template for the article to batch add the attributes.
I'm no Python guru. Do you know how this warning can be avoided? Probably at some place, my Tiger Python-2.3 stuff is used, although 2.5 is available and the first in my $PATH.
2006/12/14 15:49 +0200 [-] /private/var/automount/home/strauss/Developer/CalendarServer/twistedcaldav/directory/appleopendirectory.py:30: exceptions.RuntimeWarning: Python C API version mismatch for module opendirectory: This Python has API version 1013, module opendirectory has version 1012.
No clue! :) Josh -- Josh Wisenbaker U, U, D, D, L, R, L, R, B, A, Start for your server http://www.afp548.com
Just FYI- The server on trunk no longer uses the CalendarPrincipalURI attribute on users, groups, and resources; all records are presently provisioned regardless of whether this attribute or present or not. The reason for this is that we are going to implement a new directory schema, which is still in the works. We found that having the server host name in the user records was kind weak, because if you change the host name, you have to update all of your user records. So we'll be using some intermediate record type to store server access information and point the user records at that. -wsv On Dec 14, 2006, at 9:45 AM, Josh Wisenbaker wrote:
What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"?
The FQDN of the principal. "https://test.afp548.com:8443/principals/user/josh"
On Dec 14, 2006, at 11:59 PM, Wilfredo Sánchez Vega wrote:
Just FYI-
The server on trunk no longer uses the CalendarPrincipalURI attribute on users, groups, and resources; all records are presently provisioned regardless of whether this attribute or present or not.
The reason for this is that we are going to implement a new directory schema, which is still in the works. We found that having the server host name in the user records was kind weak, because if you change the host name, you have to update all of your user records. So we'll be using some intermediate record type to store server access information and point the user records at that.
Heh. There goes that time spent... ;-) Thanks for the update though, Josh
-wsv
On Dec 14, 2006, at 9:45 AM, Josh Wisenbaker wrote:
What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"?
The FQDN of the principal. "https://test.afp548.com:8443/principals/user/josh"
-- Josh Wisenbaker, ACSA http://www.afp548.com We're the M in RTFM.
Wilfredo Sánchez Vega wrote:
Just FYI-
The server on trunk no longer uses the CalendarPrincipalURI attribute on users, groups, and resources; all records are presently provisioned regardless of whether this attribute or present or not.
The reason for this is that we are going to implement a new directory schema, which is still in the works. We found that having the server host name in the user records was kind weak, because if you change the host name, you have to update all of your user records. So we'll be using some intermediate record type to store server access information and point the user records at that.
I'm not sure whether such an indirection would really make life easier. If some LDAP client wants to get information on a user, this information is usually available by a request on the user's LDAP entry, and that's all. For example, if I want to get Frank's email address, I request the attribute "email" from my entry on our LDAP server and get back "strauss@ibr.cs.tu-bs.de". That's it. It's not that I just get "strauss" and a pointer to another piece of information that will tell me that our institute currently has the email domain name "ibr.cs.tu-bs.de". The domain name is a kind of information that is hopefully well chosen when it was introduced and that changes very very rarely. So the benefit of easy access to the full email address is more important than an easy way to change it sometime in the future. And even _if_ we would have to change it, a simple script would do the job easily in the LDAP database. All the places out there where this information is already stored cannot be changed, anyway. I think the same holds true for calendar principal URIs. I would prefer to add a note to the server documentation that the CalDAV server name should be well chosen (e.g., a "role name" like cal.ibr.cs.tu-bs.de, not the canonical host name) and keep the directory schema simple as it is now. Just my $.02 PS: Just curious: Are there counter examples where such a kind of indirection is already modeled in LDAP schemas?
Frank Strauß wrote:
[...] Where did you take the OID 1.3.6.1.4.1.63.1001.1.1.1.1.99 from? Is it kind of official? Does it matter in any way which OID we use (as long as we are testing it in our own environments)?
What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"?
[Continuing to talk to myself... :-)] I got the LDAP backend running now. Cool. ;-) To share the answers to my questions with others that could be interested... I use another OID from our organization's own namespace. So it seems the OID does not matter wrt the LDAP protocol. However, namespace conflicts should be avoided, of course. I use "local" principal URIs like "/principal/user/strauss". Minor note for people not using Apple's OD, but any other LDAP server: Your entries have to have apple-generateduid attributes. For now, I use something like "DEADBEEF-0000-0000-0002-000000001801" (just filling in the Posix UID/GID at then end to achieve uniqueness), but like the OID question, I should probably make sure how to do it "correctly".
On Thu, December 14, 2006 12:45 pm, Frank Strauß wrote:
Frank Strauß wrote:
[...] Where did you take the OID 1.3.6.1.4.1.63.1001.1.1.1.1.99 from? Is it kind of official? Does it matter in any way which OID we use (as long as we are testing it in our own environments)?
What values do you put into calendarPrincipalURI attributes? Full URIs with a "http://cal.example.com:8008" prefix or just something like "/principals/user/josh"?
[Continuing to talk to myself... :-)]
I got the LDAP backend running now. Cool. ;-) To share the answers to my questions with others that could be interested...
You have it getting principals from LDAP?
I use another OID from our organization's own namespace. So it seems the OID does not matter wrt the LDAP protocol. However, namespace conflicts should be avoided, of course.
I use "local" principal URIs like "/principal/user/strauss".
Minor note for people not using Apple's OD, but any other LDAP server: Your entries have to have apple-generateduid attributes. For now, I use something like "DEADBEEF-0000-0000-0002-000000001801" (just filling in the Posix UID/GID at then end to achieve uniqueness), but like the OID question, I should probably make sure how to do it "correctly".
You can use uuidgen to make new UUIDs. Josh -- Josh Wisenbaker U, U, D, D, L, R, L, R, B, A, Start for your server http://www.afp548.com
Josh Wisenbaker wrote:
I got the LDAP backend running now. Cool. ;-) To share the answers to my questions with others that could be interested...
You have it getting principals from LDAP?
Yes. Users and groups, no resources yet.
You can use uuidgen to make new UUIDs.
Ah, thanks. It makes me sleep better knowing that there is nothing "magic" in the value of a UUID.
On Dec 14, 2006, at 5:26 PM, Frank Strauß wrote:
Josh Wisenbaker wrote:
I got the LDAP backend running now. Cool. ;-) To share the answers to my questions with others that could be interested...
You have it getting principals from LDAP?
Yes. Users and groups, no resources yet.
Cool. It's neat isn't it. Now if there were only more complete clients.
You can use uuidgen to make new UUIDs.
Ah, thanks. It makes me sleep better knowing that there is nothing "magic" in the value of a UUID.
The only magic is that it is unique. Really unique according to the man page, "A UUID is made unique over both space and time". :) Josh -- Josh Wisenbaker, ACSA http://www.afp548.com Breaking my server to save yours.
participants (3)
-
Frank Strauß
-
Josh Wisenbaker
-
Wilfredo Sánchez Vega