Bug 2266562

Summary: [Non Contanerized NSFS] CreateMultipartUpload operation is failing with "Access Denied" error
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Uday kurundwade <ukurundw>
Component: Multi-Cloud Object GatewayAssignee: Nimrod Becker <nbecker>
Status: CLOSED ERRATA QA Contact: Uday kurundwade <ukurundw>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.15CC: muagarwa, odf-bz-bot, rayalon
Target Milestone: ---Keywords: Automation, AutomationBlocker
Target Release: ODF 4.16.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.16.0-39 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-07-17 13:14:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Uday kurundwade 2024-02-28 10:19:31 UTC
Description of problem (please be detailed as possible and provide log
snippests):
CreateMultipartUpload operation is failing with "Access Denied" error

Version of all relevant components (if applicable):
noobaa-core-5.16.0-20240225.el8.x86_64

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes

Is there any workaround available to the best of your knowledge?
Not sure

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
1

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
NA

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. Deploy and configure Non containerized NSFS
2. Initiate multipart upload using boto3 
3.


Actual results:
E           botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the CreateMultipartUpload operation: Access Denied

Expected results:
It should initiate multipart upload

Additional info:

Comment 3 Romy Ayalon 2024-02-29 14:00:33 UTC
Hey Uday,

I was able to reproduce the bug locally, and I found that it could happen currently only on the --from-file flow.
As you know we currently working on a PR that should fix this flow and it also fixes the reported issue (After merging - https://github.com/noobaa/noobaa-core/pull/7779/- a user won't be able to specify an email that is different than the account's name)

My findings regarding the bucket policy authorization bug are -
On system_owner/is_owner check of authorize_request_policy() we still check for an email identifier instead of a name. If someone uses --from-file flow he might be able to insert an account email that is not equivalent to the account's name (providing an email is deprecated on the regular manage_nsfs flags flow and soon will be deprecated on --from-file flow).

A proper fix to this issue contains the following 2 PRs - 
1. Authorization by name - https://github.com/noobaa/noobaa-core/pull/7859
2. Fix and deprecate email using from-file flow - https://github.com/noobaa/noobaa-core/pull/7779/ (currently supports account add, the following PR should fix account update and bucket add/update)

A W/A can be to set the email and name of the account to be the same/ use the flags flow.
Can you check the W/A so you won't be blocked?

Comment 8 Uday kurundwade 2024-03-27 11:31:17 UTC
Hi Romy,

On version "noobaa-core-5.16.0-20240326.el8.x86_64", I am able to perform CreateMultipartUpload operation.

Based on this, Moving bz to verified state

Uday

Comment 11 errata-xmlrpc 2024-07-17 13:14:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Red Hat OpenShift Data Foundation 4.16.0 security, enhancement & bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:4591