Skip to content
This repository has been archived by the owner. It is now read-only.

CalDAV server should block clients from attempting to write new files into Inbox #127

Closed
macosforgebot opened this issue Apr 19, 2007 · 6 comments

Comments

@macosforgebot
Copy link

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as ticket:152


4/11/07 9:05 PM Bruce: Today we observed that clients are allowed to write files into the Inbox. That is a client bug. But it would be great if the CalDAV server caught this error too.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Apr 19, 2007

@wsanchez originally submitted this as comment:1:⁠ticket:152

  • Description modified

4/12/07 6:35 AM Cyrus Daboo: Strictly speaking the spec does not disallow writing to Inbox. However the utility of that is not clear.

What we can simply do in our case is deny at least DAV:write-content privilege to DAV:all on the Inbox. We should probably do the same for Outbox.

4/12/07 12:00 PM Wilfredo Sanchez: I don't think anyone other than the server itself should be allowed to create a resource in the inbox. I assume the CalDAV spec doesn't require that we allow it, so let's simply decide not to. I vote for denying DAV:all and granting DAV:read and DAV:unbind on the inbox collection, which isn't really own by the user so much as by the server.

On the outbox, I'd removing DAV:all and grant enough privs to do the CalDAV POST operations...

4/12/07 8:22 PM Cyrus Daboo: On Inbox, DAV:read and DAV:unbind are not enough. DAV:write-properties is needed to be able to change the CALDAV:calendar-free-busy-set property, and DAV:write-acl is needed to control the CALDAV:schedule privilege. In theory we might need DAV:lock/unlock once we have LOCK support.

Similar issues with Outbox: at least DAV:write-acl is also needed.

Why don't we simply bypass ACL altogether and just prevent a PUT on Inbox in the same way we prevent MKCOL on calendar collections.

4/13/07 11:00 AM Wilfredo Sanchez: It's slightly trickier; MKCOL happens on the calendar resource, PUT happens on a child of the inbox. I guess we can catch that in locateChild()

4/13/07 5:59 PM Cyrus Daboo: We already special case MKCOL and PUT by looking up the parent and then enforcing restrictions. It would be simple to extend that logic to special case Inbox/Outbox as the parent too.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 30, 2007

@wsanchez originally submitted this as comment:2:⁠ticket:152

  • Milestone changed from 1.0 to 1.1
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Dec 15, 2007

@wsanchez originally submitted this as comment:3:⁠ticket:152

  • Milestone changed from 1.1 to 1.2
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 10, 2008

@wsanchez originally submitted this as comment:4:⁠ticket:152

  • Milestone changed from 1.2 to 2.x
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Oct 26, 2009

@wsanchez originally submitted this as comment:5:⁠ticket:152

  • Owner changed from @wsanchez to @cyrusdaboo
  • Milestone changed from CalendarServer-2.x to CalendarServer-3.x
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Aug 1, 2011

@wsanchez originally submitted this as comment:6:⁠ticket:152

  • Radar deleted
  • Status changed from new to closed
  • Milestone changed from CalendarServer-3.x to CalendarServer-3.0
  • Resolution changed from to Software changed

Since there is no storage for inbox in the new data store, this should now be impossible

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.