Permissions

Filesystem Permissions

<PATH-OR-UUID> specifies the file that this permission is associated with. The ACL service (which checks filesystem permissions) knows if the value is a path or UUID based on the presence of a leading slash; if it starts with "/" it's a path.
<ACCESS-LEVEL> specifies one of: write, read, list, see; where each item in that list implies all the access levels which follow.
A permission that grants access to a directory, such as /user/shared, implies access of the same access level to all child file or directory nodes under that location, recursively; fs:/user/shared:read implies fs:/user/shared/nested/file.txt:read
The "real" permission is fs:<UUID>:<ACCESS-LEVEL>; whenever path is specified the permission is rewritten. note: future support for other filesystems could make this rewrite rule conditional.

<NAME-OF-SITE> specifies the subdomain that this permission is associated with. Here, "subdomain" means the "name of the subdomain", which means a site accessed via my-name.example.site will be specified here with my-name.
This permission is always rewritten as the permission described below (backend does this automatically).

If the subdomain is not protected, this permission is ignored by the system.
If the subdomain is protected, this permission will allow access to the site via a Puter app iframe with a token for the entity to which permission was granted

<NAME-OF-APP> specifies the app that this permission is associated with.
This permission is always rewritten as the permission described below (backend does this automatically).

If the app is not protected, this permission is ignored by the system.
If the app is protected, this permission will allow reading the app's metadata and seeing that the app exists.