# Wildland sharing this presentation [unrealistically] assumes you have no idea on Wildland sharing --- ### What is sharing? **Sharing** is a storage-agnostic way to grant an **access** to the **resource** for the entity identified with a Wildland public key. Note: - **Entity** can be anything identified with a WL key (*device*, *user*, *machine*, *script*). Adding your new device to the forest can be also seen as sharing. - **Resource** can be: *container*, *directory*, *file*, or *forest*. - **Access** can be *read-only* or *read-write*. - Under the hood it all **boils down to the container sharing**. --- ### Modules involved in sharing ![](https://i.imgur.com/uOLcRFZ.png) Note: - **AdminManager** -- asks storage controller for the new storage to be appended to the container to be shared (unless container already have sufficient storage attached), implements share logic reusing CoreX primitives. - **CoreX** -- paths -> container resolving, verifies/signs containers' using Wallet service, is able to modify container/storage params using ACB API. - **ACB client** -- abstracts away ACB operations. <!-- ![](https://i.imgur.com/fIxWPMG.png) --> --- ### Sharing example ```mermaid sequenceDiagram actor Alice Alice ->> AdminMgr: RO share /photos with Bob AdminMgr ->>+ CoreX: get containers claiming /photos CoreX ->>+ ACB: get containers ACB ->>- CoreX: containers[] CoreX ->>+ Wallet: get Alice priv key Wallet ->>- CoreX: Alice priv key CoreX ->>+ AdminMgr: containers[] claiming /photos loop AdminMgr ->>+ Storage Controler: get RO storage template for container's storage [conditional if RO storage not already in the container] Storage Controler ->>- AdminMgr: storage template for /photos sharing (RO) end AdminMgr ->>+ Wallet: get Bob's key(s) Wallet ->>- AdminMgr: PKbob loop AdminMgr ->> CoreX: update container manifest CoreX ->>+ Wallet: get Alice priv key Wallet ->>- CoreX: Alice priv key CoreX ->>+ ACB: update manifests ACB ->>- CoreX: done CoreX ->> AdminMgr: done end actor Bob Alice -->> Bob: Hey Bob, check out /photos! I've just shared them with you! ``` *Alice* wants to *read-only* share `/photos` -- both metadata (i.e. paths) and storage -- with *Bob*. Note: - Possibly the container is already shared. - Possibly multiple containers claim `/photos`. - Admin Manager, after getting decrypted containers verifies the signatures. - CoreX decrypts container with keys fetched from the Wallet. - *get Bob's key(s)* means get all of his `signers` (not just `master`) - If RO storage already there, ask CoreX to append Bob's pub key to the RO storage. Otherwise ask storage controller for new RO-storage and do the same. --- #### Container visualization before Alice to Bob sharing <!-- .slide: data-transition="none" --> ![](https://i.imgur.com/xIticoM.png) Note: - It all boils down to the container sharing. - Blue parts are encrypted with the respective `S` symmetric keys. --- #### Container visualization after Alice to Bob sharing <!-- .slide: data-transition="none" --> ![](https://i.imgur.com/q8LiTJv.png) --- <!-- #### Container's ACLs from the CoreX perspective --> ![](https://i.imgur.com/ri6OvZ2.png) <!-- <style> .ui-comment-inline-span { background: red; } .heatMap tr:nth-child(2) { background: blue; } .heatMap tr:nth-child(3) { background: green; } </style> <div class="heatMap"> Commonly used share combinations: 1, 2, 4 (as discussed during the meeting) 1 = read-only container sharing 2 = read-write container sharing 4 = adding new device | | Metadata | Files on the storage | Comment | | - | -------- | -------------------- | ---------------------------------------------------------------------------------------------------------- | | 1 | RO | RO | typically this is what we mean by sharing a '**RO container**' | | 2 | RO | RW | typically this is what we mean by sharing a '**RW container**' | | 3 | RW | RO | (uncommon) if we want other people to modify our paths but not the files | | 4 | RW | RW | **adding user's new device** (i.e. adding forest's new signer) | | 5 | RO | - | **RO forest sharing**: files not shared at all - neither RO nor RW; **useful for tools visualizing the forest** | | 6 | RW | - | (uncommon) files not shared at all - neither RO nor RW, just RW metadata | | 7 | - | RO | (uncommon) metadata not shared at all - just RO credentials to the storage | | 8 | - | RW | metadata not shared at all - just RW credentials to the storage; **useful for the storage syncer** | </div> --> --- ### Revoking example ```mermaid sequenceDiagram actor Alice Alice ->> AdminMgr: revoke Bob's RO share to /photos AdminMgr ->>+ CoreX: get containersclaiming /photos CoreX ->>+ ACB: get containers ACB ->>- CoreX: containers[] CoreX ->>+ Wallet: get Alice priv key Wallet ->>- CoreX: Alice priv key CoreX ->>+ AdminMgr: containers[] claiming /photos loop AdminMgr ->>+ Storage Controler: rotate RO credentials to /photos storage Storage Controler ->>- AdminMgr: done end AdminMgr ->>+ Wallet: get Bob's key(s) Wallet ->>- AdminMgr: PKbob loop AdminMgr ->> CoreX: update container manifest<br />with new RO credentials<br />+ remove Bob from access lists CoreX ->>+ Wallet: get Alice priv key Wallet ->>- CoreX: Alice priv key CoreX ->>+ ACB: update manifests ACB ->>- CoreX: done CoreX ->> AdminMgr: done end actor Bob Alice -->> Bob: Hey Bob, you no longer have access to /photos! ``` *Alice* wants to revoke Bob's *read-only* access to `/photos`. Note: - AdminMgr revokes the storage by iterating over all storages in the container and re-generates storage access credentials. --- ### Forest sharing - **read-only forest sharing** is giving read-only access to all of the forest's containers metadata alone, i.e. with no access (even RO) to the storage. - **read-write forest sharing** is giving read-write access to both the forest's containers metadata and the file kept in them. ```yaml type: forest forestid: 0xmyforest master: 0xmasterfingerprint signers: - 0xmasterfingerprint # optional - 0xBob catalog: https://cool-forest.com ``` Notes: - *read-write forest sharing* is same thing as sharing the container with RW for both metadata and files + appending the Bob's key to `signers` (implementation of adding a Signer will most likely update Containers access). --- # The End
{"metaMigratedAt":"2023-06-16T21:37:56.210Z","metaMigratedFrom":"YAML","title":"Wildland sharing","breaks":true,"slideOptions":"{\"transition\":\"slide\"}","contributors":"[{\"id\":\"4842542a-92f1-49b1-8fa6-6a1be3d1c326\",\"add\":21626,\"del\":14493}]"}
    149 views