-
Notifications
You must be signed in to change notification settings - Fork 242
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
Improvement/cldsrv 428 put apis implicit deny #5450
Improvement/cldsrv 428 put apis implicit deny #5450
Conversation
Hello benzekrimaha,My role is to assist you with the merge of this Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
9df29db
to
c55e153
Compare
ping |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command:
Alternatively, the |
/create_integration_branches |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/7.70
$ git merge origin/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/8.6
$ git merge origin/w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/8.7/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/8.7
$ git merge origin/w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/8.7/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_integration_branches |
af38aae
to
e590b47
Compare
History mismatchMerge commit #c55e153902f161d09b545e8717c26b4a5de6bad0 on the integration branch It is likely due to a rebase of the branch Please use the The following options are set: create_integration_branches |
/reset |
Reset completeI have successfully deleted this pull request's integration branches. The following options are set: create_integration_branches |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/7.70
$ git merge origin/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/8.6
$ git merge origin/w/7.70/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/8.7/improvement/CLDSRV-428-put-apis-implicitDeny origin/development/8.7
$ git merge origin/w/8.6/improvement/CLDSRV-428-put-apis-implicitDeny
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/8.7/improvement/CLDSRV-428-put-apis-implicitDeny The following options are set: create_integration_branches |
ping |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_integration_branches |
@bert-e create_pull_requests |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
Follow integration pull requests if you would like to be notified of The following options are set: create_pull_requests, create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_pull_requests, create_integration_branches |
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.
With context that the 7.70 apis are being added seperately, looks good to me
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.
It is complicated to review the PR due to the linter changes.
Would you be able to help point out in the tests which tests actually have logic changes and need review?
Other than that some over all logic looks good.
Lastly, the commit messages need to be self explanatory and it should be a commit story. Here we have a large commit cherry-picked and then a "fixups" commit. Once this is merged, looking back in the commit history it will be extremely difficult to debug.
If we are making 1 to 2 big commit, I would recommend removing all linter changes and only have logical changes or having a commit story with short logical commits.
if (!Array.isArray(requestType)) { | ||
requestType = [requestType]; | ||
} | ||
async.waterfall([ |
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.
Ideally, we should add a return here to make sure event loop execution as per our need.
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.
} | ||
return null; | ||
} | ||
|
||
|
||
/** metadataValidateBucketAndObj - retrieve bucket and object md from metadata |
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.
NIT: JS doc needs an update as well.
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.
@@ -249,6 +243,9 @@ function objectPutCopyPart(authInfo, request, sourceBucket, | |||
splitter, | |||
next, | |||
) { | |||
const originalIdentityAuthzResults = request.actionImplicitDenies; | |||
// eslint-disable-next-line no-param-reassign |
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.
Why are we disabling this linter rule eslint-disable-next-line no-param-reassign
?
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.
Given the asynchronous nature of the operations and the manipulation of shared objects (like request), there's a risk of race conditions. Care should be taken to ensure that the shared state is managed safely.
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.
same for other places.
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.
The request object is unique per API call so there's no risk of race conditions accessing it so I think that we can still delete on the request object.
}, | ||
(retentionInfo, next) => standardMetadataValidateBucketAndObj(metadataValParams, request.actionImplicitDenies, |
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: Why did we change the sequence here?
Do we know why it was the other way around before?
@@ -3,20 +3,17 @@ const async = require('async'); | |||
const crypto = require('crypto'); | |||
const { parseString } = require('xml2js'); | |||
const AWS = require('aws-sdk'); | |||
const { metadata } = require('arsenal').storage.metadata.inMemory.metadata; |
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.
adding comment here as well for shorthand
but might be at other places.
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following reviewers are expecting changes from the author, or must review again: The following options are set: create_pull_requests, create_integration_branches |
Adding integration PR reveiw here: I haven't reviewed other integration branches, as I am uncertain which merge commit has extra changes with all the linter changes. Removing the linters will help with that, or I need your help in pointing out which merge commits have more logic changes. I am thinking of changes which might have taken place during conflicts (if any) |
@@ -58,7 +58,7 @@ function objectPut(authInfo, request, streamingV4Params, log, callback) { | |||
} | |||
const invalidSSEError = errors.InvalidArgument.customizeDescription( | |||
'The encryption method specified is not supported'); | |||
const requestType = 'objectPut'; | |||
const requestType = request.apiMethods || 'objectPut'; |
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.
For consistency between the request property name and the defaults, we might want to set all defaults as arrays, even if we recreate one if needed later
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.
in the standardMetadataValidateBucketAndObj
function the requestType is set to an array if it's not the case , so the outcome will be the same
// eslint-disable-next-line no-param-reassign | ||
delete request.actionImplicitDenies; |
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.
I have done it in the PoC but I'm not sure it's safe enough; if we make additional APIs with HTTP calls based on the current request object in any API, we might run into problems because of the new properties we've added for convenience.
Another approach I had in mind was to create a new parameter (or extend the authResult of the 'AuthInfo' class) for all APIs to transmit the authz results in a safe way, to avoid this kind of code. If not possible, we should at least store the field names in a globally-defined constant and use an helper to cleanup the request everytime we need to. And document it
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.
As the request object is unique per api call this delete will not be impacting other API calls , how will the additional properties impact new API calls ?
For the change in authInfo this will alter all the changes that have already been made and merged for this epic.
Cc : @anurag4DSB
Closing this PR , a new one is opened here : #5456 |
PR opened after closing : #5325
Bucket policies are not correctly interpreted, this is part of the following epic to fix that: scality/Arsenal#2181
This PR is aiming to update put apis since object and bucket authorisations are made at API level and need to support implicit denies, ticket linked to this issue here : https://scality.atlassian.net/browse/CLDSRV-428
PRs providing implicit Deny logic to CS for processing in this PR
scality/Arsenal#2181
https://github.com/scality/Vault/pull/2135
#5322
#5420
#5432
Green CI for tests against zenko on 8.7 branch here : https://github.com/scality/Zenko/actions/runs/6956317229/job/18929846711
https://github.com/scality/Zenko/actions/runs/6967777856
https://github.com/scality/Zenko/actions/runs/6967837993/job/18962214972
I'll be bumping a new CLDSRV once the reviews done as these are changes that will be tested against Integration