Please note: the tagging feature is at this point experimental. Do not use.

Objects in the system can be marked using name/value-pairs that are called tags. Currently the only objects supported by tagging are zones. Tag names and values can contain characters except control characters (such as backspace). A zone can have several different tags and the same tag can be applied to several, different objects.

All tag modifications and permission denieds (with regard to tags) are logged in the system's syslog (e.g. /var/log/messages), depending on the actual system configuration.

The system also supports adding/removing/modifying tags and associating/unassociating tags with regard to zones and/or groups via the command line interface. Tags can also be specified as a search/filter criterion on the zone index page as well as the Advanced Search feature under the DNS-section in the main menu.

Restrict access to objects by tag

On a group's modification page, a list of tags can be associated with the group, which acts as a whitelist regarding what objects and tags a user belonging to the group can access and modify. In addition to this there is a selector that when checked, restricts both user access to zones as well as the user's modification rights of tags.

If one of the user's groups does not have tag restrictions enabled for zones, then the user does not have tag restrictions enabled at all (e.g. the admingroup should not have it checked). I.e. a user only has tag restrictions ebanlded if all of the user's groups have tag restrictions on.

A user can only access an object if the object has at least one of its tags assigned to at least one of the user's groups (i.e the zone's and the user's tags must intersect). If a user has tag restrictions enabled, then he/she can only add and remove tags that he/she has access to. A user cannot remove the last tag that gives him/her access to an object. (Otherwise the object would disappear from him/her.)

If a user belongs to several groups and all of them have tag-based access restrictions enabled, then the set of tags that enable access to objects for that user are the union of all tags in all of the user's groups. If at least one of the user's groups have tag restrictions selector enabled on the group page, then the user does not have any tag-based access restrictions at all.

An example tag use case

An instance of this system is used to administer zones belonging to different customers and the different customers should not be able to see or modify other customer's zones nor be able to even determine what other customers are using the same system. For this purpose, the administrator of the system (i.e. the super user) wants to use tags in order to restrict users to only be able to access their own zones and only be allowed to add/remove certain tags to their zones.

First, the administrator creates one group for each customer and adds the customer's users to their groups accordingly. Then, for each customer-specific group separately, the administrator adds the tags that are relevant for each customer. For example, the customer "Example ISP" is only allowed to create and access zones with the tags <Customer:Example ISP> and/or <Customer:Subsidiary of Example ISP> so the administrator then tags the customer's group with these tags and enables tag restrictions for the group using the selector "Restrict access to zones based on tag values" under the section "Access to objects by tag" on the group's group modification page. (Note that the characters "<", ">" and ":" are allowed characters in tag names and values and are only used in this help file for illustrative purposes. In the actual system graphical elements are used to separate tag names and values from each other.)

The users of the customer group specified by the administrator above are then only allowed to see and edit zones with either the tag <Customer:Example ISP> or <Customer:Subsidiary of Example ISP> (or both). These are also the only tags that the users of this group can add and remove to/from zones. Additionally, in order to protect zones from "disappearing" (due to the tag-based access rights specifications) users with tag based restrictions cannot remove the last tag that gives access to a zone and they need to specify at least one of the whitelisted tags during zone create.

Corner cases

Following the example use case above, where customers (and their data) should be completely isolated from each other, administrators need to make sure the tags that are associated with the groups do not overlap, as this would give them access to data tagged with any of the overlapping tags. For example, if the administrator has specified the tag <Comment:Obsolete> to be whitelisted to two different groups belonging to two different customers (which they can freely add to their zones), then they can see and edit each other's zones having this tag (unless other than tag-based access restrictions apply).

Note, that if a user belongs to one group with tag restrictions enabled as well as another with them disabled, then the user does not have any tag restrictions at all. Additionally, the effective tag whitelist for a user is the union of all of the tag whitelists in all of the user's groups.

Note, that an empty tag whitelist in a group that is has tag restrictions enabled restricts all access to all objects that supports tagging (zones currently), because the system tries to match against tags in an empty whitelist (which is conceptually impossible to satisfy).

Technically, tags created in the system are common for all objects in the system and are associated using so called foreign key references in the database. When an association between a tag and an object is removed, only the reference is removed, not the tag itself. This means that if a tag is created in the system, and subsequently all references to it are removed, then the tag remains as an orphan in the system. Orphans do not affect the behaviour of tags in any way, except that they appear in the list of tags currently in the system, which is accessible via the command line tool. In order to remove a tag completely from the system, all associations to it need to be removed and then the tag itself must be removed using the command line tool. (Orphans cannot be removed via the UI.)