iloveeyjafjalla opened a new issue, #11446: URL: https://github.com/apache/rocketmq/issues/11446
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in Apache RocketMQ, not a usage question. - [x] I can reproduce this on the current `develop` branch. ### RocketMQ Version develop @ `5d68880cbdfa5c6d87b5681c5eb3684df0e18ef8` (the revision this was verified on) ### Describe the Bug `mqadmin createUser -p <secret>` and `mqadmin updateUser -p <secret>` run the password through `StringUtils.trim` before calling the admin API: ```java String username = StringUtils.trim(commandLine.getOptionValue('u')); String password = StringUtils.trim(commandLine.getOptionValue('p')); // <-- the secret String userType = StringUtils.trim(commandLine.getOptionValue('t')); ``` A secret is a payload, not a name. RocketMQ stores the secret it is given (`AuthMigrator` copies `accessConfig.getSecretKey()` into the user record, `User.of(accessKey, secretKey, ...)` in the authentication manager) and every client is authenticated against exactly that string, so leading or trailing whitespace is part of a legal secret - and secrets pasted from a vault or a file routinely carry one. The CLI silently stores the trimmed value, so: - `mqadmin createUser -u bob -p " s3cret " -b 127.0.0.1:10911` stores `s3cret`; - every client that presents the real secret `" s3cret "` is rejected as unauthenticated, and nothing in the CLI output or the broker log points at the difference; - through the admin API the same secret is stored verbatim, so the CLI and the API disagree about the same user. The neighbouring command `sendMessage` carried the same shape for the message body until #11414 dropped its `.trim()`. ### Steps to Reproduce 1. `mqadmin createUser -u bob -p " s3cret " -b 127.0.0.1:10911` (or `updateUser`). 2. Query the stored user: `mqadmin getAcl/`... the stored secret is `s3cret`, not the string that was passed. 3. Start a client with `s3cret`-with-spaces and one with the trimmed value: the first is rejected, the second succeeds. A unit test makes the same point without a broker: the mocked `DefaultMQAdminExt` receives `"s3cret"` for the argument `" s3cret "`: ``` CreateUserSubCommandTest.testCreateKeepsThePasswordVerbatim:65 expected:<[ s3cret ]> but was:<[s3cret]> UpdateUserSubCommandTest.testUpdateKeepsThePasswordVerbatim:65 expected:<[ p@ss word ]> but was:<[p@ss word]> ``` ### What Did You Expect to See? The password reaches `createUser` / `updateUser` exactly as the operator passed it. The username, the user type and the broker address keep their trim. ### What Did You See Instead? Both commands trim the secret, so a secret with leading or trailing whitespace cannot be provisioned through mqadmin at all, and the mismatch only shows up later as an authentication failure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
