user permissions
Hackiki instances with OpenID support (such as this one) have an etc/permissions file which gives the ability to allow only certain users to perform certain edits.
Each line contains one command.
Editors
Permissions are assigned to editors. Editors may be:
- Users, identified by their OpenIDs.
- Groups, created within etc/permissions and described below.
- Scripts, which may have greater permissions than the end users running them by the theory that they implement their own security procedures. Scripts are identified by their name immediately after "#!", e.g. "#!medit".
Note that in essence scripts are treated as if they are users, so a user running the script medit has their OpenID and "#!medit" as simultaneous editor IDs.
Groups
group [group name] [group members]
creates a group. Groups may be used anywhere that editor IDs can be used. There are two builtin pseudo-groups: all (for all users) and anonymous (for users not authenticated by OpenID). Groups may contain users, scripts, and earlier-defined groups.
regexgroup [group name] [group member regexes]
creates a group based on regexes. If any current editor ID matches any of the regexes, the editor is considered to be part of the group. This is most useful for whitelisting scripts to perform certain actions, as in the example etc/permissions at the bottom of this page.
File permissions
file [file regex] [ID] [permission]
gives the given editor ID the given permission over the given file. The permission can be 'r' or 'w', for read access or read/write access (preventing read access is presently impossible). The filename is actually a regular expression (PCRE), so multiple files can be handled in one line. Note that the permission granted for a given file is the permission of the LAST matching line. So, for example, this will give codu.org write access to etc/permissions:
file etc/permissions all r file etc/permissions codu.org w
But this will not:
file etc/permissions codu.org w file etc/permissions all r
Note that no magical permissions to edit etc/permissions are given, so a nasty misstep will prevent anyone from updating etc/permissions (except by direct mercurial access)
By default, all users have write access to all files. That is, etc/permissions is read as if the first line is
file .* all w
Script interpreter permissions
(Don't be confused, this section is about limiting the permissions on the interpreters of written scripts, not limiting the permissions of running scripts)
script [interpreter regex] [ID] [permission]
gives the given editor ID the given permission over scrips (anything executable) with the given interpreter. Again the permission granted for a given file is the permission of the LAST matching line.
The interpreter is the part of the chebang line after "#!". If there is no chebang line, the interpreter is "none". Note that the entire line is matched, so
script /usr/bin/env all w
does not give all editors the ability to create scripts with any option to /usr/bin/env, but
script /usr/bin/env\ .* all w
does.
By default, all editors have write access to scripts of all interpreters. That is, etc/permissions is read as if the first line is
script .* all w
Note that an editor must have both file AND script permissions over any executable file to write it.
Mercurial access
Note that the /hg pseudopage (Mercurial FS access) has the same restrictions as any other page, so malicious users can't revert if that reversion affects files in a way that etc/permission denies.
Example
The following example simply allows anyone to edit anything, with the exception that only administrators (in this case the only administrator is codu.org) can edit etc/permissions. It furthermore guarantees that etc/permissions is only edited by the builtin editor (edit), thereby preventing malicious code from external users that could edit etc/permissions from working if run by an administrator.
group administrators codu.org regexgroup !#!edit #!(?!edit$).* file etc/permissions all r file etc/permissions administrators w file etc/permissions !#!edit r