[MCOL-4347] SM hits assertion if ms3_init_assume_role() fails Created: 2020-10-12  Updated: 2020-10-15  Resolved: 2020-10-15

Status: Closed
Project: MariaDB ColumnStore
Component/s: Storage Manager
Affects Version/s: 5.4.1
Fix Version/s: 5.4.1

Type: Bug Priority: Major
Reporter: Patrick LeBlanc (Inactive) Assignee: Jose Rojas (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

centos 8, engine build 922, cmapi build 315


 Description   

I ran into an assertion in S3Storage trying to reproduce the problem in MCOL-3976. My acct didn't have the assume-role permission, so ms3_init_assume_role() failed, and getConnection() returned NULL. The NULL went into ScopedConnection, which asserts on NULL.

The change to make here is to check the return value from getConnection(), and if NULL, return an error (set errno to something appropriate and return -1).

 Comments   
Comment by Ben Thompson (Inactive) [ 2020-10-13 ]

getConnection() returns NULL if libmarias3 ms3_init() or ms3_init_assume_role() fail
ms3_init() is highly unlikely to fail as we do adequately check in constructor for at least some value for s3 key/secret is set in config.
ms3_init_assume_role() is more likely to fail as it attempts to assume a role during init meaning IAM and STS requests are performed. This can fail for many reasons related to both user input in config (role name wrong), role permission errors, or network issues resulting in the request not reaching the desired endpoint.
This fix provides better error handling ensuring that it does not rely on assert in ScopedConnection or failing the request because ms3_st is NULL.

Comment by Jose Rojas (Inactive) [ 2020-10-15 ]

Verified assertion no longer exists in build columnstore-1.5.4-1/push/934 , and there is now an intuitive error msg in logs.

Generated at Thu Feb 08 02:49:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.