Subadmin can create newgroup using userprovisioning API

[paurakhsharma]

Steps to reproduce

1. Create a user subadmin and make him subadmin of a group new-group

2. perform curl http://subadmin:123456@example.com/ocs/v1.php/cloud/groups -d groupid="newgroup"

3. and see there is status code is 100 in API-v1 and 200 in API-v2

4. and see there is new group newgroup

Expected behaviour

Subadmin should not be able to create new group

Actual behaviour

Subadmin can create new group

Server configuration

Operating system: 17.10

Web server: Apache

Database: MySQL

PHP version: 7.1

ownCloud version: (see ownCloud admin page) 10.1.0

Where did you install ownCloud from: git

Log in terminal

When I ran

curl http://subadmin:123456@localhost:80/core/ocs/v1.php/cloud/groups -d groupid="newgroup"

I got

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>100</statuscode>
  <message/>
 </meta>
 <data/>
</ocs>

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @phil-davis.

Possibly related issues are #31263 (API test to test userprovisioning API-v2), #29698 (a group called "0" cannot be created by provisioning API), #31276 (Unusual response(997) from userprovisioning api-v2 ), #29712 (Allow group 0 to be created by provisioning API), and #4885 (Create a version for each public api class).

[phil-davis]

We were a bit surprised about this. But I suppose that it just allows sub-admins to create group names without needing to bother the all-powerful admin.

Is there a requirements spec somewhere for what sub-admins should and should not be able to do?

Then we will know if the behavior is by design, or unintended.

[PVince81]

Does the subadmin have the option of creating groups in the web UI ? This is unlikely.
I don't think this is by design...

[phil-davis]

In the webUI a subadmin does not see the add group box. So cannot add groups.

Note: we have not yet tested the "private" API that the webUI uses to do all this sort of user/group provisioning stuff. So it is possible that that "private" API behaves in some interesting ways. But that is hidden from the everyday webUI user, unless they hack around changing the AJAX/POST etc stuff that happens from their browser. When we get the provisioning API behavior sorted, then we should test equivalent actions attempted via the "private" API.

[patrickjahns]

😠 - I hope with phoenix we can finally get rid of "public" vs "private" api - and only have api so there can't be any difference

[phil-davis]

Agree - and the term "private API" is a misnomer. It is open-source code, so hardly "private". Anyone can read the code and then try interesting ways to make use of it.

[patrickjahns]

I was more interested in having a unified codepath to be used by frontend and other parts

[sharidas]

@PVince81 Estimate : 1md.