mirror of
https://github.com/nspcc-dev/neofs-api.git
synced 2026-03-01 04:28:54 +00:00
getrangehash doesn't work with a bearer token created via cli #105
Labels
No labels
I0
I1
I2
I3
I4
S0
S1
S2
S3
S3
S4
U2
U3
U4
bug
discussion
discussion
documentation
enhancement
enhancement
enhancement
feature
good first issue
question
task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neofs-api#105
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @evgeniiz321 on GitHub (Sep 1, 2023).
Related to https://github.com/nspcc-dev/neofs-testcases/pull/621
Current Behavior
getrangeandgetrangehash)getrangehash:In logs there are the following entries at the time of the failure:
Expected Behavior
The command should work with this bearer token. All other commands work ok.
Steps to Reproduce
test_bearer_token_expiration- allure.tar.gzRegression
(No)
Your Environment
Run on current latest master of neofs-node - 98717120a74c62b328b45f036f770b02685fb9b8
@roman-khimov commented on GitHub (Sep 1, 2023):
The problem is that getrangehash needs getrange to operate and it's a valid requirement (consider hashing a part of the large object). So any permission set that allows getrangehash only is useless (see https://github.com/nspcc-dev/neofs-spec/blob/master/01-arch/07-acl.md#extended-acl also). But the deeper problem in fact is that we have an insane ACL system that can't be explained to people and that doesn't add any value despite all of its complexity.
Allowing to GET, but not allowing to GETRANGE is like allowing
read(), but not allowingmmap()(yeah, this has some difference SECCOMP-wise (RSBAC if anyone remembers), but that's a different problem). Allowing GETRANGEHASH, but not allowing to GET/GETRANGE does not protect data from being read, it just makes it a little harder to do that. There is absolutely zero security added (data can be read with any of these three), just a maintenance burden and configuration headache.In short, protocol verbs are not the thing users operate with when they think about access. One can set different bits to these different verbs, but they will break in one way or another, so no one even tries (these verbs are configured identically). People usually think in terms of some rwx Unix model, even when they think of S3 actions they expect an action to work on its own, not require anything additional.
Specifically, get/getrange/getrangehash are the same thing. GETRANGE can be deleted completely and be a parameter of GET. GETRANGEHASH is somewhat specific to audit, so it can either be made tied to GET permission or just be available to system nodes with no user access at all (what application needs it?).
@evgeniiz321 commented on GitHub (Sep 1, 2023):
In the failure above I generated a bearer token with the following command -
So getrange should be allowed together with getrangehash