mirror of
https://github.com/nspcc-dev/neofs-s3-gw.git
synced 2026-03-01 04:29:15 +00:00
Directory sync commands don't set the right ACL to objects #328
Labels
No labels
I2
I2
I3
I4
S2
S3
S4
S4
U0
U1
U2
U2
U3
U4
U4
auth-mate
blocked
bug
config
dependencies
discussion
documentation
enhancement
epic
feature
go
good first issue
help wanted
performance
question
security
test
tree-service
tree-service
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neofs-s3-gw#328
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 @anikeev-yadro on GitHub (Aug 26, 2022).
I have tried to use the following commands with parameter "--acl public-read-write":
with the same result - objects ACL for AllUsers set to public-read instead of public-read-write
Log:
Product versions:
s3 gateway config:
@KirillovDenis commented on GitHub (Aug 26, 2022):
Actually READ for object means full control (so just output a little incorrect #677 should fix this issue) because WRITE cannot be applied to object https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#permissions
@KirillovDenis commented on GitHub (Aug 29, 2022):
@anikeev-yadro Could you try to reproduce this bug using
nspcc-dev/neofs-s3-gw@ece40d5972commit and see if it's getting better?@anikeev-yadro commented on GitHub (Aug 30, 2022):
Now it's looks like better.
After we have been uploaded objects with --acl public-read-write:
we see the corresponding ACL:
But I still see errors about ACL in the log:
s3 gate version:
@KirillovDenis commented on GitHub (Aug 30, 2022):
It would be nice to see parameters for
authmatecommand@anikeev-yadro commented on GitHub (Aug 30, 2022):
authmate command:
bearer_rules.json
@KirillovDenis commented on GitHub (Aug 31, 2022):
It seems we cannot do anything with this error:
When we create two objects (that require updating EACL) simultaneously, two transactions fall into one block and we can get success result only for one of such EACL update (because we expect eacl table that was sent to be match eacl table that currently can be got).
/cc @alexvanin
@alexvanin commented on GitHub (Aug 31, 2022):
We can do some hacks if requests are sent into the same gateway, e.g. queue AST changes and produce one SetEACL invocation per block. But it is error prone and will not work if requests are sent into two different gateways. But maybe it is good enough for such cases.
@alexvanin commented on GitHub (Oct 3, 2022):
We've decided to propose new mechanism to work with extended ACLs in the container smart contract. Until that we are blocked (or required to build some really dirty fixups in the code).