Closed amrita-shrestha closed 6 months ago
cc @rhafer
Hm, currently we can not do any better than that :disappointed:.
The two different editor rules are pretty ugly. Currently the condtitions on the roleDefinitions do not allow to distinguish between Folders and files. That's why we are always returning both roles.
Also we always return the full list of of actions, ignoring whether they makes sense for the requested resource.
We have to find at least some way to avoid the two different Editor
roles.
@rhafer @butonic @fschade I propose to use the same "Editor" Role on files and folders. Semantically that should not break any behavior.
I propose to use the same "Editor" Role on files and folders. Semantically that should not break any behavior.
Hm, looking at the reva code, I think that would break stuff. The Editor
role does have the Delete
Permission while the FileEditor
role does not have that. I.e. assigning the Editor
role to a user on a file, would allow that user to delete the file. Which we do not want I think.
For the roles we might want to rethink our usage for the Condition
property in RolePermissions
. We currently allow the following there hardcoded conditions:
// UnifiedRoleConditionSelf defines constraint where the principal matches the target resource
UnifiedRoleConditionSelf = "@Subject.objectId == @Resource.objectId"
// UnifiedRoleConditionOwner defines constraints when the principal is the owner of the target resource
UnifiedRoleConditionOwner = "@Subject.objectId Any_of @Resource.owners"
// UnifiedRoleConditionGrantee does not exist in MS Graph, but we use it to express permissions on shared resources
UnifiedRoleConditionGrantee = "@Subject.objectId Any_of @Resource.grantee"
UnifiedRoleConditionSelf
is basically unused in our codebase, we just have it because it's one of the two conditions that MSGraph defines :man_shrugging:
We use UnifiedRoleConditionOwner
for indicating that a set of AllowedResourceActions
can be applied to project spaces. (This condition is also defined in MSGraph as the "owner" condition.)
The third one UnifiedRoleConditionGrantee
is not defined MSGraph. We use it do indicate that a set for AllowedResourceActions
can be applied to other shared resource (files/directories)
IMO this is all but intuitive. It's hard to understand. The syntax is not explained anywhere (at least AFAIK). And the two conditions we're actively using look just arbitrary.
How about if we define a set of conditions that are somewhat more explicit. E.g. depending on the driveitem properties:
@Resource.File != null
to match files@Resource.Folder != null
to match folders@Resource.Root != null
to match spacesI must admit that I don't grasp the whole RolePermission.Conditions
thing enough to judge whether this makes any sense. Who does? (Really!)
With the above condtions we could in theory just define a single Editor
role that expands to different ResourceActions depending on the resource type it is assigned to. Something like:
func NewEditorUnifiedRole() *libregraph.UnifiedRoleDefinition {
return &libregraph.UnifiedRoleDefinition{
Id: proto.String(UnifiedRoleEditorID),
Description: proto.String("View, download, upload and edit."),
DisplayName: "Can Edit"
RolePermissions: []libregraph.UnifiedRolePermission{
{
AllowedResourceActions: convert(conversion.NewSpaceEditorRole()),
Condition: "@Resource.Root != null",
},
{
AllowedResourceActions: convert(conversion.NewEditorRole()),
Condition: "@Resource.Folder != null",
},
{
AllowedResourceActions: convert(conversion.NewFileEditorRole()),
Condition: "@Resource.File != null",
},
},
LibreGraphWeight: proto.Int32(0),
}
}
But in order to keep the "Descriptions" more accurate we could also keep the current roles as they are and just filter them properly using the new conditions.
@micbar @butonic I think this needs your input.
I would agree with the observation that the current conditions are not clean enough.
The suggestion is also ok, the naming is understandable.
Let us please decide quickly how we can handle the idea of a Role that can expand into different Resource Actions.
@butonic @kobergj @kulmann @JammingBen
We need to really understand what model makes it "easier" to understand. (harhar)
This discussion is quite old:
So why even differentiate between the two permissions?
IMO we need to seperate them.
AFAICT it follows the Security Descriptor Definition Language (SDDL) for Conditional ACEs - Conditional expressions:
AttributeName Operator Value
I think rules like this will become relevant in the future:
Policy
Allow read access if
the user has logged in with a smart card,
is a backup operator, and
is connecting from a machine with Bitlocker enabled.
SDDL
D:(XA; ;FR;;;S-1-1-0; (Member_of {SID(Smartcard_SID), SID(BO)} && @Device.Bitlocker))
That should clarify the syntax. But we should probably
I already deviated from MS graph because we needed permissions that only applied to shared resources, hence the "@Subject.objectId Any_of @Resource.grantee"
condition.
Instead of @Resource.Root != null
I would prefer exists @Resource.Root
AFAICT the Conditions do not need to be parsed by anyone, do they? So I'm ok with changing the way we write them, as long as they follow the SDDL Conditional Expressions.
Regarding the Condition Syntax
AFAICT it follows the Security Descriptor Definition Language (SDDL) for Conditional ACEs - Conditional expressions:
AttributeName Operator Value
I think rules like this will become relevant in the future:
Policy
Allow read access if the user has logged in with a smart card, is a backup operator, and is connecting from a machine with Bitlocker enabled.
SDDL
D:(XA; ;FR;;;S-1-1-0; (Member_of {SID(Smartcard_SID), SID(BO)} && @Device.Bitlocker))
That should clarify the syntax.
Yeah. Obviously. :exploding_head:
I really have strong doubts going down that rabbithole. But that's a discussion to be had when it becomes relevant.
Instead of
@Resource.Root != null
I would preferexists @Resource.Root
Fine with me.
Describe the bug
File resource list extra permission like
Editor(file or folder) and Uploader
. Folder resource list extra permission likeEditor(Allows reading and updating file)
Related issue https://github.com/owncloud/ocis/issues/8131Steps to reproduce
parent.txt
and folder resourcetestFolder
parent.txt
item,curl -vk 'https://host.docker.internal:9200/graph/v1beta1/drives/{drives-id}/items/{items-id}/permissions'
Editor(file or folder)
andUploader
role API request returns400 status code
testFolder
item,Expected behavior
Editor(file or folder) and Uploader
permission shouldn't listed for file resources and EDitor(Allows reading and updating file) should not be listed on folder resourceActual behavior
four permission listed for both file and folder resource
Setup
Please describe how you started the server and provide a list of relevant environment variables or configuration files.
```console OCIS_XXX= master OCIS_YYY= 8.0.0-rc.1 PROXY_XXX=somevalue ```
Additional context
Add any other context about the problem here.