Jump To: Support > KB > NetManager > Calendars > ACL
Controlling access to shared calendars and contacts
Access is controlling with the/etc/netmanager/calendar.acl
file. If not present, each user will have read-write access to their own calendars and contacts, but no access to any other. This is equivalent to a calendar.acl
file containing just the following (you will probably want to ensure any file you create contains this):USER:w USER
A more complicated example /etc/netmanager/calendar.acl is:
ALL:w jsmith bob @admin PUBLIC:r ALL PUBLIC:w fbloggs @staff USER:w USER ALLUSER:r ALL jsmith:w @staff
First column is either username or one of the following:
- ALL = all calendars on the system
- PUBLIC = just calendars at the root i.e. along the lines of
http://netmanager/dav/calendarname.ics/
- USER = calendars belonging to the user you are logged on as, i.e. all calendars beginning with
http://netmanager/dav/yourusername/
- ALLUSER = all user calendars (i.e. ALLUSER+PUBLIC=ALL)
This is then followed by :r (for read-only) or :w (for write).
The second and later columns are users, groups (if preceded by @), ALL (for everyone who has logged in), GUEST (for anyone who hasn't logged in) or USER (for the user you are logged on as).
To split down the example file above this means:
ALL:w jsmith bob @admin
- All calendars writable by jsmith, bob and members of group adminPUBLIC:r ALL
- Public calendars are readable by everyonePUBLIC:w fbloggs @staff
- Public calendars are writable by fbloggs and members of group staff (also jsmith, bob and members of group admin as they can write to all calendars)USER:w USER
- Users can write to their own calendarsALLUSER:r ALL
- Everyone can read everyone else's calendarminibus:w @staff
- All staff can write to the minibus calendar group (not necessary to have a user called minibus, see Fine-grained control section below)
Checking access
To check access for a particular user, the simplest method to log onto the web-based calendar/contact interface. This will show all calendars and contacts that the user has access to and whether they are read-only or read/write:
Fine-grained control
Public calendars/contacts are all-or-nothing, if you have write access to one, you have access to all. If you want more fine-grained control over calendars/contacts (e.g. grant access to a specific list of people), you can use a calendar-group name instead of a username in the first column and after /dav/
in the calendar address. The calendar-group name can be anything you wish, but should not correspond to an existing username (usernames are actually the same as personal calendar-groups). So for example, if 3 people (usera, userb and userc) want a shared finance calendar you could use:
finance:w usera userb userc
You'd then use http://netmanager/dav/finance/finance.ics/ as the calendar address