[CalendarServer-users] Access Control Documentation

[Frank Strauß]

Wilfredo Sánchez Vega wrote:

>> After some weeks, yesterday I tried to get a fresh SVN checkout
>> running again. First, I had to change this to check out some
>> dependencies at the "./run -s" step successfully:
>>
>> Index: run
>> ===================================================================
>> --- run (revision 1125)
>> +++ run (working copy)
>> @@ -296,7 +296,7 @@
>>      fi;
>>    else
>>      echo "Checking out ${name}...";
>> -    svn checkout -r "${revision}" "${uri}@${revision}" "${path}";
>> +    svn checkout -r "${revision}" "${uri}" "${path}";
>>
>>      apply_patches "${name}" "${path}";
>>    fi;
> 
>   This is necessary only if you have an old version of subversion
> installed.  If you update subversion, the script should work as-is.

Ok. (Just curious: Does it have any benefit to give the revision twice?)

>> After I got the server running (this time on Linux and without LDAP
>> directory binding), I was curious what has changed regarding access
>> control. I still just don't understand which of the limitations of
>> this calendar service compared to usual WebCAL access are intended
>> and  which are not. Since it's claimed to conceptually be an extension
>> of WebCAL I would expect to be able to create hierarchies and to
>> adjust ACLs as usual, but in many locations this seems to be not working.
> 
>   I assume you mean CalDAV, not WebCAL?

Uh. Sure.

>> I'm not sure whether you (the core developers) are interested in a
>> discussion of this in more detail. (I've sent comments in the past
>> without a response.) I could perfectly understand, if you are not, due
>> to other more important things to work on first. I guess, time is
>> pressing a bit. :-)
> 
>   We do care, but, as you note, we are trying to get a lot done in a
> short amount of time, and that's made it hard to be responsive.  I hope
> that will get better soon.
> 
>> *If* you like to get more helpful input, IMHO we need more
>> documentation. What's the intended purpose of items in the hierarchy
>> layout (e.g., sudoers, locations, resources)? How can people adjust
>> access control? Where can people put own hierarchies and calendars?
> 
>   I agree.  Part of the problem is that we have been adding a lot of
> functionality in quickly, and when things settle down a bit (we're
> pretty close to done now), we can document where we are.
> 
>> Unfortunately, my time is too limited to try to find out everything on
>> my own at this stage of the project where things keep changing.
> 
>   Understood.

Thank you very much for your response. AFAICT, you are doing a good job.
 I'm looking forward to what the future will bring. :-)
-------------- next part --------------
Spam detection software, running on the system "bierator.ibr.cs.tu-bs.de", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  Wilfredo Sánchez Vega wrote: >> After some weeks,
  yesterday I tried to get a fresh SVN checkout >> running again. First,
  I had to change this to check out some >> dependencies at the "./run
  -s" step successfully: >> >> Index: run >>
  =================================================================== >>
  --- run (revision 1125) >> +++ run (working copy) >> @@ -296,7 +296,7
  @@ >> fi; >> else >> echo "Checking out ${name}..."; >> - svn checkout
  -r "${revision}" "${uri}@${revision}" "${path}"; >> + svn checkout -r
  "${revision}" "${uri}" "${path}"; >> >> apply_patches "${name}"
  "${path}"; >> fi; > > This is necessary only if you have an old version
  of subversion > installed. If you update subversion, the script should
  work as-is. [...] 

Content analysis details:   (5.9 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%
                            [score: 0.5000]
 2.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
                            [82.83.49.97 listed in dnsbl.sorbs.net]
 3.8 RCVD_IN_DSBL           RBL: Received via a relay in list.dsbl.org
                            [<http://dsbl.org/listing?82.83.49.97>]
 0.1 RCVD_IN_NJABL_DUL      RBL: NJABL: dialup sender did non-local SMTP
                            [82.83.49.97 listed in combined.njabl.org]