Per-object access setting #48

New issue

Open

opened 2025-12-28 18:12:11 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:12:11 +00:00

Owner

Originally created by @fyrchik on GitHub (Jun 28, 2021).

Currently we have 2 (?) ways to share a collection of objects in our container with somebody:

Update eACL with the rule including objects ID (or some attribute) and public key to access them with.
Create a new container and push everything you need there.

Both of these are sub-optimal. eACL rule based on attribute values is not really an option in (1) because objects are already in the system so the only thing we are left with is to enumerate object ids. (2) doesn't scale well.

In essense the problem is to have per-object access settings without overloading eACL. Also, "sharing an object" doesn't look like an operation which requires altering container-level eACL.

One of the solutions is to introduce a linking object (similar to symlink in a file-system), which can have it's own headers, but share payload with the object it links to. This way we can have a single eACL rule like allow to GET objects with attribute ShareWith=123 for this public key. To share an object we can only put a link with the needed attribute in the container. To revoke access, simply delete an object (this plays nicely with an expiration epoch). While it can also be done with the help of some pre-defined attribute, I believe it is worth to be reflected in the API.

Originally created by @fyrchik on GitHub (Jun 28, 2021). Currently we have 2 (?) ways to share a collection of objects in our container with somebody: 1. Update eACL with the rule including objects ID (or some attribute) and public key to access them with. 2. Create a new container and push everything you need there. Both of these are sub-optimal. eACL rule based on attribute values is not really an option in (1) because objects are already in the system so the only thing we are left with is to enumerate object ids. (2) doesn't scale well. In essense the problem is to have per-object access settings without overloading eACL. Also, "sharing an object" doesn't look like an operation which _requires_ altering container-level eACL. One of the solutions is to introduce a linking object (similar to symlink in a file-system), which can have it's own headers, but share payload with the object it links to. This way we can have a single eACL rule like `allow to GET objects with attribute ShareWith=123 for this public key`. To share an object we can only put a link with the needed attribute in the container. To revoke access, simply delete an object (this plays nicely with an expiration epoch). While it can also be done with the help of some pre-defined attribute, I believe it is worth to be reflected in the API.