Can't suspend accounts that belong to reseller

[pqpier]

Can't suspend -- via API -- accounts that belong to resellers.

Is this the expected behavior?

Is there any way to allow/bypass this restriction?

Error from API:

{
metadata: {
result: 0,
command: 'suspendacct',
version: 1,
reason: 'API failure: (XID 2e88vm) You do not have access to an account named “ltzutnreak7ank2”.'
}
}

 

[cPRex]

Hey there! In order to test this I did the following, so let me know if your process is different:

-Create a Reseller
-Login to WHM as that Reseller and create a new account
-Access SSH as root
-Call the suspendacct tool:

[[email protected] ~]# whmapi1 suspendacct user="cptest"
---
metadata:
  command: suspendacct
  output:
    raw: "Changing Shell to /bin/false...Done\nLocking Password...Done\nSuspending mysql users\nSuspending websites...\nSuspending FTP accounts...\nSuspending outgoing email....Done\ncptest's account has been suspended\n"
  reason: OK
  result: 1
  version: 1

That worked well on my end, so I can't say for sure what you experienced. Is that the correct testing procedure?

 

[pqpier]

Nope, as I mentioned, I'm trying to do it via cpanel API: Suspend cPanel account

I gave the API token privilege to suspend accounts and it works fine if "root" is the account owner.
However, if account owner is a reseller and not "root", the API gives me the mentioned response:

{
metadata: {
result: 0,
command: 'suspendacct',
version: 1,
reason: 'API failure: (XID 2e88vm) You do not have access to an account named “ltzutnreak7ank2”.'
}

Hey there! In order to test this I did the following, so let me know if your process is different:

-Create a Reseller
-Login to WHM as that Reseller and create a new account
-Access SSH as root
-Call the suspendacct tool:

[[email protected] ~]# whmapi1 suspendacct user="cptest"
---
metadata:
  command: suspendacct
  output:
    raw: "Changing Shell to /bin/false...Done\nLocking Password...Done\nSuspending mysql users\nSuspending websites...\nSuspending FTP accounts...\nSuspending outgoing email....Done\ncptest's account has been suspended\n"
  reason: OK
  result: 1
  version: 1

That worked well on my end, so I can't say for sure what you experienced. Is that the correct testing procedure?

 

[rbairwell]

I've been able to replicate this myself on my test server (reminder: I'm just a fellow customer and not a member of staff). It seems to be a hidden privilege which is included in the "all" API level but not listed in the "Manage API Tokens"

Reproduction steps:
1. As "root" under WHM, create a reseller ("reseller") and create an account under their reseller account (called "resellertest" in my test)
2. As "root" under WHM "Manage API tokens", create a new token with "will not expire", empty whitelisted IPs and every privilege ticked (but not "Everything->All features (all)")
3. Take a note of the API token provided ("xxxx")
4. Use SSH as root to try and suspend the "resellertest" account as per the API guide:

curl -k -H'Authorization: whm root:xxxx' 'https://127.0.0.1:2087/json-api/suspendacct?api.version=1&user=resellertest'

Receive the response:

{"metadata":{"version":1,"result":0,"command":"suspendacct","reason":"API failure: (XID 97768n) You do not have access to an account named “resellertest”."}}

5. Check in WHM that the account is NOT suspended.
6. Return to "Manage API tokens" and only change the "Everything->All features (all)" box at the bottom to be ticked/active and save.
7. Repeat step 4:

curl -k -H'Authorization: whm root:xxxx' 'https://127.0.0.1:2087/json-api/suspendacct?api.version=1&user=resellertest'

and receive the response:....

{"metadata":{"output":{"raw":"Changing Shell to /bin/false...Done
Locking Password...Done
Suspending mysql users
Suspending websites...
Suspending FTP accounts...
Suspending outgoing email....Done
resellertest's account has been suspended
Success[2022-10-30 18:08:52 +0000] info [xml-api] ---debug_hooks---
[2022-10-30 18:08:52 +0000] info [xml-api]             msg: Beginning execution of module hook.
[2022-10-30 18:08:52 +0000] info [xml-api]         context: Whostmgr::Accounts::suspendacct
[2022-10-30 18:08:52 +0000] info [xml-api]           stage: post
[2022-10-30 18:08:52 +0000] info [xml-api]          result: 0
[2022-10-30 18:08:52 +0000] info [xml-api]           point: main
[2022-10-30 18:08:52 +0000] info [xml-api]              id: 8b96b7d9-3cf7-4a74-9b39-9eb79be212e4
[2022-10-30 18:08:52 +0000] info [xml-api]            hook: NginxHooks::_just_clear_user_cache
[2022-10-30 18:08:52 +0000] info [xml-api]          weight: 100
[2022-10-30 18:08:52 +0000] info [xml-api]            data: {\"result\":1,\"args\":{\"user\":\"resellertest\",\"reason\":\"\",\"disallowun\":0},\"user\":\"root\"}
[2022-10-30 18:08:52 +0000] info [xml-api] ---debug_hooks---
[2022-10-30 18:08:52 +0000] info [xml-api]             msg: Finished execution of module hook.
[2022-10-30 18:08:52 +0000] info [xml-api]         context: Whostmgr::Accounts::suspendacct
[2022-10-30 18:08:52 +0000] info [xml-api]           stage: post
[2022-10-30 18:08:52 +0000] info [xml-api]          result: 1
[2022-10-30 18:08:52 +0000] info [xml-api]           point: main
[2022-10-30 18:08:52 +0000] info [xml-api]              id: 8b96b7d9-3cf7-4a74-9b39-9eb79be212e4
[2022-10-30 18:08:52 +0000] info [xml-api]            hook: NginxHooks::_just_clear_user_cache
[2022-10-30 18:08:52 +0000] info [xml-api]          weight: 100
[2022-10-30 18:08:52 +0000] info [xml-api]            data: {\"result\":1,\"args\":{\"user\":\"resellertest\",\"reason\":\"\",\"disallowun\":0},\"user\":\"root\"}
"},"reason":"OK","command":"suspendacct","result":1,"version":1}}

8. Check in WHM that the account IS suspended.

I've raised this as cPanel ticket 94498998 and I'll keep you updated once there's been an update.

 

[cPRex]

@pqpier - thanks for letting me know the suspension was happening as the reseller, as that wasn't clear to me initially.

I'll double-check this on my end and let you know my findings soon.

 

[pqpier]

@pqpier - thanks for letting me know the suspension was happening as the reseller, as that wasn't clear to me initially.

I'll double-check this on my end and let you know my findings soon.

Thanks, also please check @rbairwell response.

He did the exact steps and was able to reproduce the issue.
And he opened a ticket as well: 94498998

 

[cPRex]

Since you've submitted a ticket, I'll let our team handle things there!

 

[rbairwell]

Aaron from cPanel tech support has just responded:

....
I was able to replicate this behaviour easily with your posted steps. I appreciate the thoroughness that you went through in order to provide the instructions. Having tested and replicated the API key permissions in different contexts, I believe that this is by design.

The API key functions as root, but with the default permissions, it does not have "full root" permissions. What this means is that the API key has the necessary permissions to affect accounts that are owned by root directly and not those that are owned by another user. You can see this same behaviour if you create a reseller and select the option to make the account own itself. The same API key would no longer be able to function on that account.

When selecting the "Everything-ALL" option, you are giving the API key full root permissions, much like you would have through the WHM interface, and are then able to execute commands on accounts that root does not directly own. The "root" account owner functions similarly to that of a reseller. If you consider that account suspension privileges can be given to the API keys generated by resellers themselves, then it would make sense that an API key created without "full" permissions should be limited to only the accounts directly owned by that reseller, otherwise resellers would be allowed to suspend other reseller's accounts.
....

I'm going to think about this overnight to see if that's how I personally would expect it to work: but any comments/thoughts from @pqpier would be appreciated.

 

[rbairwell]

Aaron has again responded:

I can understand if the warning does not necessarily imply that the user is granted more than is listed on the page. This is clarified in our more specific documentation on API Tokens and the permissions given here:
https://docs.cpanel.net/whm/development/manage-api-tokens-in-whm/

Warning:
Use caution when you assign the following ACL privileges:

• Everything — This allows an API token user access to the entire system. A user with this token can perform all root user functions.

Where the API functions are concerned, you must have root permissions to affect an account that is not your own or that is not owned by your user. With the way that the system is designed, this is a blanket scenario. Either you have permission to affect users that aren't yours, or you don't, and this is reflected in the Everything flag: this token is to be given permission to affect all users on the system. Where the API functionality is concerned, being a token of the root user does not automatically grant you root permissions, which is what is necessary to do certain functions and to affect users that do not belong to you.

This is reflected more clearly in a different scenario. If you were using these tokens created by a reseller account, you would have full access to suspend and create accounts that you own without these permissions blocks because the only accounts that the reseller can see and access are those that it owns. If you were to put in the name of an account that the reseller does now own, then you would get the same error messages. This same functionality is applied to the root user within the token system, as to the system, all users are the same. A root-user-created token isn't given any priority unless it has the root permission flag.
....

I did suggest that since at least 3 of us have been a bit confused over the Everything/All feature (me: "Having the checkbox in Manage API tokens labelled "Everything/All features (all)" which then automatically ticks all the other options does not, at least to me, imply that "all" gives more access than everything already listed on that page. ") and the fact I feel that having to use the "All/Everything" option for anything really to do with resellers breaks the security "principle of least privilege", that an additional set of privileges should be created. Aaron suggested that this be raised on the feature request board - which I have done so here "Reseller API privileges group" : so feel free to up vote!

Not quite the outcome I would have liked, but hopefully things will be improved. If you've got any thoughts/comments, feel free to add them to that feature request or here

(as an aside, whilst filing this issue I did discover a bug with the API Reseller tool Creating a new Reseller account using an API token succeeds, but does not make the account a Reseller which is now logged as bug reference CPANEL-41821)

 

[cPRex]

I did approve that feature request just now, and I'll bring it up with the team during our meeting next week.

 

[pqpier]

Thanks @rbairwell

The additional set of privileges that you proposed is a fine solution.
Let's hope that feature will be implemented soon.

Until then, I'll be suspending accounts manually since I get shivers down my spine just from thinking about checking that "Everything — This allows an API token user access to the entire system" box.