Radicale Rights Files Define More Than Login Access

Radicale is a CalDAV and CardDAV server that stores calendars and address books in collections. Authentication answers whether a user knows a valid credential. The rights backend answers which collections that user may read, write, or share. A deployment that reviews only the password file has tested half of the boundary.

The ZoomEye measurement on 15 November 2026 returned 345 matches for app="Radicale", 3,871 for title="Radicale", and 8,862 for http.body="Radicale" with sub_type=all, page 1, and page size 1. These are index observations. They do not establish that every matching asset is reachable, current, or configured with anonymous access.

Collection paths are authorization inputs

Radicale's from_file rights backend matches rules against the authenticated user and the collection path. The first matching section determines the rights for a request, which makes rule ordering and path coverage part of the security review. A broad rule for authenticated users can unintentionally cover a shared collection that the administrator expected to protect separately.

The server's own documentation says that access to collections outside a user's /username/ directory may be granted but will not be discovered automatically by clients. That distinction matters operationally: a collection can be inaccessible in the client UI while still being reachable through a direct path. Test the path that the server accepts, not only the collection list displayed by a phone or desktop client.

Review the authentication backend, the rights file, the public users setting, and the reverse proxy. Radicale can use its integrated HTTP server or run behind a real HTTP server. The latter gives the operator more control over TLS, headers, request limits, and access logs. Whichever mode is selected, make sure the externally reachable path does not bypass the intended proxy.

Test users and collections

Create an authenticated user, an administrator, and a revoked account. Test each against its own collection, another user's collection, a shared collection, and the root. Check GET, PROPFIND, PUT, and DELETE rather than assuming that read access implies write access. Confirm that an unauthenticated request receives a denial, not an empty successful response.

Review collection exports and backups. Calendar and contact data can be sensitive even when the server has a small user count. The operator should know which files contain user credentials, which contain collection data, and whether encryption at rest is provided by the host rather than the application.

Radicale's fingerprint count is useful because the product identifies itself. It is only the beginning of the evaluation. The rights file, authentication backend, collection ownership, proxy configuration, and backup protection determine what a user can actually reach.

References

• ZoomEye
• Radicale v3 documentation
• Radicale configuration reference
• Radicale project