[CalendarServer-dev] [CalendarServer] #350: location in snow leopard, more explanation about the problem

[CalendarServer]

#350: location in snow leopard, more explanation about the problem
-----------------------------------+----------------------------------------
 Reporter:  jduffas1@…             |       Owner:  wsanchez@…        
     Type:  Defect                 |      Status:  new               
 Priority:  1: Blocker             |   Milestone:  Later             
Component:  Calendar Server        |    Severity:  Other             
 Keywords:  location snow leopard  |  
-----------------------------------+----------------------------------------
Description changed by wsanchez@…:

Old description:

> a <location> should not function as a <user>.
> normally, some people should be allowed to
> book locations (through <proxies>) but <locations> should
> always accept the booking (they have no choice to do this, they are not
> alive...)
>
> so, we can imagine that <locations> are programmated this way, and that
> the xml file should look like this:
>
>   <location>
>     <uid>rfi</uid>
>     <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid>
>     <password>dddd</password>
>     <name>rfi</name>
>     <email-address>rfi at free.fr</email-address>
>     <proxies>
>     <member type="users">jduffas</member>
>     </proxies>
>   </location>
>

> that way, only the user "jduffas" can access that <location>.
> But the problem is that the <location> accepts half the appointments:
> it leaves the question mark on the event's user
> having asked, however, the room still appears
> as reserved in the availability tool...
>
> worse, if I use another user (who is not in
> <proxies>, the server reacts completely identical.
>
> Now, if I add a <auto-schedule/>, the <location> accepts
> routinely the appointment, whatever the user is (in the
> <proxies> or not.)
>
> wholesale <proxies> in <locations> is not active,
> which represents a big security hole.
>

> the same in french (my language... i'm bad in english)
>
> un lieu ne devrait pas fonctionner comme un user.
> normalement, certaines personnes devraient être autorisées à réserver des
> lieux (grâce au proxi) mais les lieus devraient toujours accepter les
> réservation (ils n'ont pas le choix à faire, ce ne sont pas des être
> vivants)
>
> pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il
> suffit de rentrer dans le .xml quelque chose de ce genre :
>
>   <location>
>     <uid>rfi</uid>
>     <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid>
>     <password>dddd</password>
>     <name>rfi</name>
>     <email-address>rfi at free.fr</email-address>
>     <proxies>
>     <member type="users">jduffas</member>
>     </proxies>
>   </location>
>

> ainsi seul le user "jduffas" pourra accéder au lieu.
> mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse
> le point d'interrogation sur l'événement du user l'ayant demandé, en
> revanche, la salle apparait quand même comme réservée dans l'outil de
> disponibilité
>
> pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le
> serveur réagit de façon totalement identique.
>
> maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté
> systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou
> non.)
>
> en gros, <proxies> dans les <locations> n'est pas actif, ce qui
> représente une grosse faille de sécurité.

New description:

 a <location> should not function as a <user>.
 normally, some people should be allowed to
 book locations (through <proxies>) but <locations> should
 always accept the booking (they have no choice to do this, they are not
 alive...)

 so, we can imagine that <locations> are programmated this way, and that
 the xml file should look like this:

 {{{
   <location>
     <uid>rfi</uid>
     <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid>
     <password>dddd</password>
     <name>rfi</name>
     <email-address>rfi at free.fr</email-address>
     <proxies>
     <member type="users">jduffas</member>
     </proxies>
   </location>
 }}}

 that way, only the user "jduffas" can access that <location>.
 But the problem is that the <location> accepts half the appointments:
 it leaves the question mark on the event's user
 having asked, however, the room still appears
 as reserved in the availability tool...

 worse, if I use another user (who is not in
 <proxies>, the server reacts completely identical.

 Now, if I add a <auto-schedule/>, the <location> accepts
 routinely the appointment, whatever the user is (in the
 <proxies> or not.)

 wholesale <proxies> in <locations> is not active,
 which represents a big security hole.


 the same in french (my language... i'm bad in english)

 un lieu ne devrait pas fonctionner comme un user.
 normalement, certaines personnes devraient être autorisées à réserver des
 lieux (grâce au proxi) mais les lieus devraient toujours accepter les
 réservation (ils n'ont pas le choix à faire, ce ne sont pas des être
 vivants)

 pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il
 suffit de rentrer dans le .xml quelque chose de ce genre :

 {{{
   <location>
     <uid>rfi</uid>
     <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid>
     <password>dddd</password>
     <name>rfi</name>
     <email-address>rfi at free.fr</email-address>
     <proxies>
     <member type="users">jduffas</member>
     </proxies>
   </location>
 }}}

 ainsi seul le user "jduffas" pourra accéder au lieu.
 mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse le
 point d'interrogation sur l'événement du user l'ayant demandé, en
 revanche, la salle apparait quand même comme réservée dans l'outil de
 disponibilité

 pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le
 serveur réagit de façon totalement identique.

 maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté
 systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou
 non.)

 en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente
 une grosse faille de sécurité.

--

-- 
Ticket URL: <http://trac.calendarserver.org/ticket/350#comment:2>
CalendarServer </>
HTTP/WebDAV/CalDAV Server