chore: Improve project-wide prettier formatting and ignored files (#5505)

* chore: Improve project-wide prettier formatting and ignored files

* chore: `Run make fmt/prettier`

* Fix gitignore for `.vscode` folder so that ! works

* Add comment in `.prettierrc.yaml` to explain `.editorconfig`

* Remove scripts/apidocgen/markdown-template/README.md

* Use `yq` for processing prettierrc, update lib.sh dependency check

* Add `yq` to Dockerfile and Nix
This commit is contained in:
Mathias Fredriksson
2023-01-03 15:11:13 +02:00
committed by GitHub
parent 5435bceaf0
commit 856f0ab6f5
34 changed files with 784 additions and 567 deletions

View File

@ -5,7 +5,8 @@ Package `authz` implements AuthoriZation for Coder.
## Overview
Authorization defines what **permission** a **subject** has to perform **actions** to **objects**:
- **Permission** is binary: *yes* (allowed) or *no* (denied).
- **Permission** is binary: _yes_ (allowed) or _no_ (denied).
- **Subject** in this case is anything that implements interface `authz.Subject`.
- **Action** here is an enumerated list of actions, but we stick to `Create`, `Read`, `Update`, and `Delete` here.
- **Object** here is anything that implements `authz.Object`.
@ -22,6 +23,7 @@ A **permission** is always applied at a given **level**:
**Permissions** at a higher **level** always override permissions at a **lower** level.
The effect of a **permission** can be:
- **positive** (allows)
- **negative** (denies)
- **abstain** (neither allows or denies, not applicable)
@ -29,15 +31,14 @@ The effect of a **permission** can be:
**Negative** permissions **always** override **positive** permissions at the same level.
Both **negative** and **positive** permissions override **abstain** at the same level.
This can be represented by the following truth table, where Y represents *positive*, N represents *negative*, and _ represents *abstain*:
This can be represented by the following truth table, where Y represents _positive_, N represents _negative_, and \_ represents _abstain_:
| Action | Positive | Negative | Result |
|--------|----------|----------|--------|
| read | Y | _ | Y |
| ------ | -------- | -------- | ------ |
| read | Y | \_ | Y |
| read | Y | N | N |
| read | _ | _ | _ |
| read | _ | N | Y |
| read | \_ | \_ | \_ |
| read | \_ | N | Y |
## Permission Representation
@ -56,18 +57,17 @@ This can be represented by the following truth table, where Y represents *positi
## Roles
A *role* is a set of permissions. When evaluating a role's permission to form an action, all the relevant permissions for the role are combined at each level. Permissions at a higher level override permissions at a lower level.
A _role_ is a set of permissions. When evaluating a role's permission to form an action, all the relevant permissions for the role are combined at each level. Permissions at a higher level override permissions at a lower level.
The following table shows the per-level role evaluation.
Y indicates that the role provides positive permissions, N indicates the role provides negative permissions, and _ indicates the role does not provide positive or negative permissions. YN_ indicates that the value in the cell does not matter for the access result.
| Role (example) | Site | Org | User | Result |
|-----------------|------|-----|------|--------|
| site-admin | Y | YN_ | YN_ | Y |
| no-permission | N | YN_ | YN_ | N |
| org-admin | _ | Y | YN_ | Y |
| non-org-member | _ | N | YN_ | N |
| user | _ | _ | Y | Y |
| | _ | _ | N | N |
| unauthenticated | _ | _ | _ | N |
| Role (example) | Site | Org | User | Result |
| --------------- | ---- | ---- | ---- | ------ |
| site-admin | Y | YN\_ | YN\_ | Y |
| no-permission | N | YN\_ | YN\_ | N |
| org-admin | \_ | Y | YN\_ | Y |
| non-org-member | \_ | N | YN\_ | N |
| user | \_ | \_ | Y | Y |
| | \_ | \_ | N | N |
| unauthenticated | \_ | \_ | \_ | N |