Privileges

A privilege is the smallest unit of rights: it allows a set of actions on one object, a repository or an administrative area. Privileges are not granted to a user directly — a role lists them and a user is given roles (the whole model is in Access control).

Every privilege of the installation is visible on the “Settings” → “Privileges” page, and the type filter narrows the list. The catalog fills itself: the administrative privileges are created at the first start, and the privileges for a repository — together with the repository. For most tasks it is enough to pick the names you need from the catalog.

Types

The type defines what a privilege works on and which fields it has.

The same action means different things in the two repository families: add in repository-view is publishing an artifact, add in repository-admin is creating a repository.

Actions on the content

repository-view privileges operate on five actions:

What read and browse allow depends on where the request goes, and it is the same for every format.

read covers everything a format client gets in ordinary work: the file itself and the service listings it resolves dependencies from — maven-metadata.xml with its checksums, the version list of a Go module, an npm package descriptor, the PyPI, RubyGems, and Cargo indexes, the tag list of an image. A build agent that only downloads needs read alone.

browse is for the web interface: without it the repository does not appear in the “Browse” section even when downloading from it is allowed. The repository card and the component and asset lists open with either of the two actions.

Publishing container images is the exception: the client asks the registry for read and write access at once, so docker push needs both actions — read and add.

Actions on the repository

repository-admin privileges govern the repository itself: its settings and its existence.

The add action is the only one that does not apply to an existing repository: at the moment of creation there is none yet. The right to create repositories is therefore granted by a privilege that covers not one repository but all of them at once: nx-repository-admin-*-*-add allows creating repositories of any format. How such names are built is covered below.

Administrative areas

application privileges cover the operations that are not tied to a repository. The area is called a domain:

Administrative privileges have verbs of their own: create, read, update, delete, and all. A modification privilege includes reading its area: a user with nx-users-update sees the user list, and a separate nx-users-read is not needed. The settings domain has no create and delete — settings are not created or deleted, they are read and changed.

Privilege names

Privilege names follow a pattern made of the area or format, the repository, and the action. Knowing the pattern, you can compose the name you need yourself and find it in the catalog by search:

• nx-<DOMAIN>-<VERB> — administrative: nx-users-create, nx-roles-read, nx-settings-update;
• nx-repository-view-<FORMAT>-<REPOSITORY>-<ACTION> — the content: nx-repository-view-maven2-maven-releases-read;
• nx-repository-admin-<FORMAT>-<REPOSITORY>-<ACTION> — the repository itself: nx-repository-admin-docker-docker-hosted-edit.

The format and repository positions accept the * wildcard: nx-repository-view-*-*-read is reading in every repository, nx-repository-view-docker-*-browse is viewing every Docker (OCI) repository.

Two privileges fall outside the pattern:

• nx-tasks-run — running tasks and pausing the garbage collection. Only this privilege grants that right: nx-tasks-read allows viewing the state and nothing more;
• nx-userschangepw — changing one’s own password; not part of any role by default (see Initial setup).

Full access to every operation is granted by the built-in nx-all privilege — it is part of the admin role.

Where the privileges come from

The catalog is filled without the administrator’s involvement:

• the first start creates the administrative privileges for every domain and the privileges with a wildcard: for all repositories at once and for all repositories of each format;
• creating a repository produces the set of privileges for it: one per content action and one per action on the repository itself. They are removed together with the repository.

Built-in privileges are read-only: they cannot be changed or deleted. They are put into roles the same way as any other privilege.

Custom privileges

Before creating a privilege of your own, look for a suitable one in the catalog: most tasks are covered by the built-in names.

The built-in catalog leaves one case uncovered — the administrator of all repositories of one format. Ready-made repository-admin privileges with a wildcard exist only for all formats at once (nx-repository-admin-*-*-<ACTION>), while a privilege for “every Maven repository and no other” is created by hand: type repository-admin, format maven2, repository *, and the actions you need.

A privilege is created on the “Settings” → “Privileges” page with the “+ New privilege” button. The rules:

• The name. Names starting with nx- are reserved for the built-in catalog. Pick a different prefix for your own privileges, team- for example.
• The format and the repository. If a specific repository is named, it has to exist and to belong to the chosen format: a privilege with the format maven2 and the repository docker-hosted is not created. If the repository position holds *, the format still has to be one of those Galleon supports.
• The domain. The domain of an administrative privilege is not checked against the list of domains. A typo such as user instead of users raises no error: the privilege is stored, it can be put into a role, and it grants nothing at all. Check it against the domain table above.

Typical roles

What to put into a role for a particular task:

A role is assembled on the “Settings” → “Roles” page. A role can include other roles: a user with such a role gets both its own privileges and the privileges of the roles included in it. Those may include roles as well, and the privileges are collected along the whole chain. This is how a base role with the common rights is made and added to the team roles. A role cannot include itself, including through intermediate roles: the server refuses such nesting.