-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Make DAC write permission more granular #3218
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -174,6 +174,8 @@ defradb client ... --identity e3b722906ee4e56368f581cd8b18ab0f48af1ea53e635e3f7b | |
|
||
We have in `examples/dpi_policy/user_dpi_policy.yml`: | ||
```yaml | ||
name: An Example Policy | ||
|
||
description: A Valid DefraDB Policy Interface (DPI) | ||
|
||
actor: | ||
|
@@ -183,9 +185,11 @@ resources: | |
users: | ||
permissions: | ||
read: | ||
expr: owner + reader | ||
write: | ||
expr: owner | ||
expr: owner + reader + updater + deleter | ||
update: | ||
expr: owner + updater | ||
delete: | ||
expr: owner + deleter | ||
|
||
relations: | ||
owner: | ||
|
@@ -194,6 +198,12 @@ resources: | |
reader: | ||
types: | ||
- actor | ||
updater: | ||
types: | ||
- actor | ||
deleter: | ||
types: | ||
- actor | ||
``` | ||
|
||
CLI Command: | ||
|
@@ -443,8 +453,8 @@ Note: | |
- The collection with the target document must have a valid policy and resource linked. | ||
- The target document must be registered with ACP already (private document). | ||
- The requesting identity MUST either be the owner OR the manager (manages the relation) of the resource. | ||
- If the specified relation was not granted the miminum DPI permissions (read or write) within the policy, | ||
and a relationship is formed, the subject/actor will still not be able to access (read or write) the resource. | ||
- If the specified relation was not granted the miminum DPI permissions (read or update or delete) within the policy, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: These should read There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No. They are required for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I asked the right question in the wrong location!
Is there nowhere in the documentation that notes this? I see no other lines changed. thought: I'm happy with the feature, and the 4-5 lines of code that have changed, but will not approve until the PR is out of draft status :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
From line
It's worded in a generic manner so in future changing would have to be done in minimal places... so for example it says
Fair enough There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Does the doc define what the required owner permissions are? How will users know they need to define There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The same way they knew before that Which is here: However, I do understand if you are suggested to have it explicitly defined and for us to maintain it every time it is changed. LMK, if so, happy to do that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah okay - thanks Shahzad :) I have a preference for them to not have to look at a Thanks for your explanations! |
||
and a relationship is formed, the subject/actor will still not be able to access (read or update or delete) the resource. | ||
- If the relationship already exists, then it will just be a no-op. | ||
|
||
Consider the following policy that we have under `examples/dpi_policy/user_dpi_policy_with_manages.yml`: | ||
|
@@ -461,10 +471,13 @@ resources: | |
users: | ||
permissions: | ||
read: | ||
expr: owner + reader + writer | ||
expr: owner + reader + updater + deleter | ||
|
||
update: | ||
expr: owner + updater | ||
|
||
write: | ||
expr: owner + writer | ||
delete: | ||
expr: owner + deleter | ||
|
||
nothing: | ||
expr: dummy | ||
|
@@ -478,6 +491,14 @@ resources: | |
types: | ||
- actor | ||
|
||
updater: | ||
types: | ||
- actor | ||
|
||
deleter: | ||
types: | ||
- actor | ||
|
||
writer: | ||
types: | ||
- actor | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,7 +29,7 @@ var invalidIdentity = identity.Identity{ | |
DID: "did:something", | ||
} | ||
|
||
var validPolicyID string = "d59f91ba65fe142d35fc7df34482eafc7e99fed7c144961ba32c4664634e61b7" | ||
var validPolicyID string = "87480b693bdaccdbbe1c1334204b31fd1cb44d3ad70b66fab57595283714fbfe" | ||
var validPolicy string = ` | ||
name: test | ||
description: a policy | ||
|
@@ -40,10 +40,12 @@ actor: | |
resources: | ||
users: | ||
permissions: | ||
write: | ||
expr: owner | ||
read: | ||
expr: owner + reader | ||
update: | ||
expr: owner | ||
delete: | ||
expr: owner | ||
|
||
relations: | ||
owner: | ||
|
@@ -495,10 +497,23 @@ func Test_LocalACP_InMemory_CheckDocAccess_TrueIfHaveAccessFalseIfNotErrorOtherw | |
require.ErrorIs(t, errCheckDocAccess, ErrFailedToVerifyDocAccessWithACP) | ||
require.False(t, hasAccess) | ||
|
||
// Invalid empty arguments such that we can't check doc access (write). | ||
// Invalid empty arguments such that we can't check doc access (update). | ||
hasAccess, errCheckDocAccess = localACP.CheckDocAccess( | ||
ctx, | ||
WritePermission, | ||
UpdatePermission, | ||
identity1.DID, | ||
validPolicyID, | ||
"", | ||
"", | ||
) | ||
require.Error(t, errCheckDocAccess) | ||
require.ErrorIs(t, errCheckDocAccess, ErrFailedToVerifyDocAccessWithACP) | ||
require.False(t, hasAccess) | ||
|
||
// Invalid empty arguments such that we can't check doc access (delete). | ||
hasAccess, errCheckDocAccess = localACP.CheckDocAccess( | ||
ctx, | ||
DeletePermission, | ||
identity1.DID, | ||
validPolicyID, | ||
"", | ||
|
@@ -594,10 +609,23 @@ func Test_LocalACP_PersistentMemory_CheckDocAccess_TrueIfHaveAccessFalseIfNotErr | |
require.ErrorIs(t, errCheckDocAccess, ErrFailedToVerifyDocAccessWithACP) | ||
require.False(t, hasAccess) | ||
|
||
// Invalid empty arguments such that we can't check doc access (write). | ||
// Invalid empty arguments such that we can't check doc access (update). | ||
hasAccess, errCheckDocAccess = localACP.CheckDocAccess( | ||
ctx, | ||
UpdatePermission, | ||
identity1.DID, | ||
validPolicyID, | ||
"", | ||
"", | ||
) | ||
require.Error(t, errCheckDocAccess) | ||
require.ErrorIs(t, errCheckDocAccess, ErrFailedToVerifyDocAccessWithACP) | ||
require.False(t, hasAccess) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: all unit tests (I didn't see any changes in integration tests) assert that there is no access. Is there a place where you assert that there is access? |
||
|
||
// Invalid empty arguments such that we can't check doc access (delete). | ||
hasAccess, errCheckDocAccess = localACP.CheckDocAccess( | ||
ctx, | ||
WritePermission, | ||
DeletePermission, | ||
identity1.DID, | ||
validPolicyID, | ||
"", | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I'm curious why we decided not to have
write: updater + deleter