mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-13 15:22:30 +00:00
Jack YeandBrendan Clement
47b7babc08
Move the public website pages into `docs/web` beside the SDK, with
shared navigation and executable example sources in `docs/web-tests`.
The combined website is assembled by
[lancedb/docs#355](https://github.com/lancedb/docs/pull/355), with six
Enterprise replacements from
[lancedb/sophon#7681](https://github.com/lancedb/sophon/pull/7681).
This includes Function guidance, runnable Quickstarts, regenerated
snippets, production contact/demo fixes, the legacy SQL route, and the
LeRobot redirect. LeRobot remains attributed to Geneva; all 34 Geneva
pages remain in the docs repository until Function officially launches.
Materialized-view guidance follows the full rebuild refresh introduced
by #4373: local refresh writes the complete result, has no `full`
argument, supports `source_version`, and no longer requires stable row
IDs. Deployment SQL refresh options and stable-ID setup are qualified by
version/configuration. Function input guidance distinguishes ordinary
stored columns from computed inputs supported by newer deployments.
**Validation:** independently accepted local checks include 95 Python
tests (real Enterprise excluded), eight TypeScript tests, Rust
Quickstart, snippet parity, typos, deterministic assembly, Mint
validation and links/anchors/redirects. The combined baseline retains
all 181 production routes and 17 legacy redirects. Examples ran locally
against source-built Python SDK 0.40.0b13; existing GitHub workflows do
not run `docs/web-tests`. New main at `069b2f7d` is 0.41.0b0 and adds
computed Function inputs; that SDK was not exercised by the accepted
tests. Latest prose corrections receive focused site validation.
**Merge/rollout:** merge this and #7681 before #355's combined CI, which
reads producer `main`. This is migration infrastructure: section
overlays, source-owned skills and automatic versioned paired releases
remain follow-ups. The current manual publisher is transitional. Hosted
validation, a supported SDK/Enterprise release pair and a real
Enterprise walkthrough remain pending.
Production Mintlify watches `lancedb/docs:deploy-freeze`, directory
`docs`; preserve that source through review. The separate SDK GitHub
Pages reference workflow rebuilds on main merges.
**Updated-head CI (9a50f8db):**
[Typos](https://github.com/lancedb/lancedb/actions/runs/37654185443/job/112904990558),
[PR
title](https://github.com/lancedb/lancedb/actions/runs/37654179507/job/112904974595)
and
[Aikido](https://app.aikido.dev/featurebranch/scan/215386145?groupId=74229)
pass. Critical findings in the example lockfiles were patched: all Sharp
copies use 0.35.5, protobufjs 7.6.6, tar 7.5.22, quinn-proto 0.11.19,
zerovec 0.11.8 and zerovec-derive 0.11.6. The SDK's product dependencies
are unchanged. The revised lockfiles pass eight TypeScript examples,
HuggingFace decode/resize/crop/rescale/normalize plus AVIF roundtrip,
and Rust Quickstart. Aikido passing does not mean every advisory is
cleared; npm still reports 29 high and five moderate advisories in the
example dependency graph. No scanner bypass or suppression was added.
The Function prose correction passes combined/standalone Mint,
deterministic assembly, routes and assets. The revised 325-file site
checksum is
`175bec06864abb400dd292e667ba93448c0479b8359fd7bf6146afabf9040647`. This
PR remains open for independent review; further merges are on hold.
---------
Co-authored-by: Brendan Clement <brendan.clement@lancedb.com>
116 lines
4.1 KiB
Plaintext
116 lines
4.1 KiB
Plaintext
---
|
|
title: "Authorization"
|
|
sidebarTitle: "Authorization"
|
|
description: "Who may do what: privileges granted on catalog objects to principals, groups, roles, and API keys."
|
|
icon: shield-halved
|
|
keywords: ["authorization", "authz", "privileges", "rbac", "access control"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge>
|
|
|
|
This page describes a LanceDB Enterprise capability. Embedded LanceDB has no
|
|
such layer -- access is whatever the object store enforces on the bucket or
|
|
directory, which is coarser and has no concept of a table. See
|
|
[Architecture](/architecture) for what differs between the two.
|
|
|
|
[Authentication](/enterprise/authentication) establishes who is calling.
|
|
Authorization decides what they may do.
|
|
|
|
An access control entry grants **one privilege** on **one object** to **one
|
|
subject**. Everything below is a consequence of that shape.
|
|
|
|
## Subjects {#subjects}
|
|
|
|
A grant is held by one of four kinds of subject, distinguished by a prefix:
|
|
|
|
| Prefix | Subject |
|
|
| --- | --- |
|
|
| `p:` | a principal, by ID -- `P:` by name |
|
|
| `g:` | a group, by ID -- `G:` by name |
|
|
| `r:` | a role |
|
|
| `a:` | an API key |
|
|
|
|
Granting to a group or role rather than a principal is what keeps the entry
|
|
count manageable: a principal's effective privileges are the union of what it
|
|
holds directly and what it inherits.
|
|
|
|
Granting to an API key is narrower than granting to the principal that owns
|
|
it -- useful when a key is issued for one job and should not carry that
|
|
principal's full authority.
|
|
|
|
## Objects {#objects}
|
|
|
|
Objects are addressed by kind and path:
|
|
|
|
```
|
|
system
|
|
database:db
|
|
namespace:db/ns
|
|
table:db/ns/table
|
|
```
|
|
|
|
The hierarchy is not decorative. Reaching a table requires `USAGE` on the
|
|
namespace containing it and on the database containing that -- a grant on the
|
|
table alone is not enough to traverse to it.
|
|
|
|
## Privileges {#privileges}
|
|
|
|
| Privilege | Granted on | Allows |
|
|
| --- | --- | --- |
|
|
| `OWNERSHIP` | any object | ownership, conveying full authority |
|
|
| `USAGE` | database | accessing the namespaces inside |
|
|
| `USAGE` | namespace | accessing the tables inside |
|
|
| `SELECT` | table | reading rows |
|
|
| `INSERT` | table | appending rows |
|
|
| `UPDATE` | table | modifying existing rows |
|
|
| `DELETE` | table | deleting rows |
|
|
| `CREATE_DATABASE` | system | creating a database |
|
|
| `CREATE_NAMESPACE` | database, namespace | creating immediate child namespaces |
|
|
| `CREATE_TABLE` | namespace | creating a table in it |
|
|
| `CREATE_MATERIALIZED_VIEW` | namespace | creating a materialized view in it |
|
|
| `CREATE_VIEW` | namespace | creating a non-materialized view in it |
|
|
| `OPERATE` | system | reading server configuration |
|
|
|
|
The four data privileges map onto the four
|
|
[ingestion operations](/ingestion), so a principal that may append but not
|
|
modify is expressed by granting `INSERT` without `UPDATE`.
|
|
|
|
<Note>
|
|
`CREATE_MATERIALIZED_VIEW` and `CREATE_VIEW` are separate privileges because
|
|
[the two objects differ](/basics/catalog): one stores rows and is refreshed,
|
|
the other stores only a query. Granting the ability to create one does not
|
|
grant the other.
|
|
</Note>
|
|
|
|
## Creation privileges resolve upward {#upward}
|
|
|
|
A subtlety worth knowing, because it explains grants that appear to work on
|
|
objects that do not exist yet.
|
|
|
|
When `USAGE` is checked on a database and **no entries exist for it at all**,
|
|
the database is assumed not to exist yet, and `CREATE_DATABASE` on `system` is
|
|
checked instead. The same applies to the default namespace: absent any
|
|
entries, the check falls back to `CREATE_NAMESPACE` on the containing
|
|
database.
|
|
|
|
So a principal holding `CREATE_DATABASE` can act on a database that has not
|
|
been created -- which is what makes creation possible at all, and why an empty
|
|
ACL set is not the same as a deny.
|
|
|
|
## Listing grants {#listing}
|
|
|
|
Entries can be listed filtered by object, by subject, or both:
|
|
|
|
```
|
|
object = table:db/ns/documents
|
|
subject = G:data-science
|
|
```
|
|
|
|
Results paginate through a continuation token. One stored `(object, subject)`
|
|
tuple carrying several privileges expands into several entries in the
|
|
response, so the count reflects privileges rather than tuples.
|
|
|
|
Listing by subject answers "what can this team reach"; listing by object
|
|
answers "who can reach this table". Both are worth running before changing a
|
|
grant.
|