-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Deleting files in s3 buckets can trip AccessControlException #108049
Labels
>bug
:Distributed/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
Team:Distributed
Meta label for distributed team
Comments
ywangd
added
>bug
:Distributed/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
labels
Apr 30, 2024
Pinging @elastic/es-distributed (Team:Distributed) |
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this issue
May 4, 2024
This PR moves the doPrivileged wrapper closer to the actual deletion request to ensure the necesary security context is established at all times. Resolves: elastic#108049
elasticsearchmachine
pushed a commit
that referenced
this issue
May 6, 2024
This PR moves the doPrivileged wrapper closer to the actual deletion request to ensure the necesary security context is established at all times. Also added a new repository setting to configure max size for s3 deleteObjects request. Fixes: #108049
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this issue
May 6, 2024
This PR moves the doPrivileged wrapper closer to the actual deletion request to ensure the necesary security context is established at all times. Also added a new repository setting to configure max size for s3 deleteObjects request. Fixes: elastic#108049
ywangd
added a commit
to ywangd/elasticsearch
that referenced
this issue
May 6, 2024
This PR moves the doPrivileged wrapper closer to the actual deletion request to ensure the necesary security context is established at all times. Also added a new repository setting to configure max size for s3 deleteObjects request. Fixes: elastic#108049 (cherry picked from commit bcf4297) # Conflicts: # docs/reference/snapshot-restore/repository-s3.asciidoc # modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3BlobStore.java
elasticsearchmachine
pushed a commit
that referenced
this issue
May 6, 2024
…08299) This PR moves the doPrivileged wrapper closer to the actual deletion request to ensure the necesary security context is established at all times. Also added a new repository setting to configure max size for s3 deleteObjects request. Fixes: #108049 (cherry picked from commit bcf4297) # Conflicts: # docs/reference/snapshot-restore/repository-s3.asciidoc # modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3BlobStore.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
>bug
:Distributed/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
Team:Distributed
Meta label for distributed team
Since 8.13.0, the task runs in the background to delete stale files of snapshots can sometimes run into
AccessControlException
. The most relevant stacktrace is show below. It's been identified that the issue is with runningdeletePartition
inside the lambda ofMapIterator.forEachRemaining
which changes the stack frame for SecurityManager and makes the top leveldoPrivilegedVoid
not effective. The lambda version offorEachRemaining
was introduced in #103581 which is part of the 8.13.0 release. We should changedoPrivileged
call to be tightly around the necessary networking call to re-establish correct the permission grant.The text was updated successfully, but these errors were encountered: