If a user is able to change his own group, he can make himself an SuperAdmin. So you can as well give him core.admin permissions because the effect is exactly the same.

What is your reason why you want the user to allow his own group (which is a nightmare from a security view)?

Explain will be long...

So short :
If i don't want to allow an administrator user to access of all settings (eg: super admin), but i want to allow him to change his own group, actually this is not possible

I'm aware of the security concern, and of my specific use case

Think about a web agency

• SuperUser = developper of web agency
• Administrator = customer of web site, editing joomla configuration not really wanted but changing there groups could be possible

NB : We could add : disallow administrator giving him super admin, allow only super admin to give super admin ! ;)

A user must not be able to elevate their own permissions. This means they must not be able to change the user group(s) their account is assigned to and that another user with equal or greater privileges to the group(s) the account is to be added to must perform the change.

@Devportobello Just give him a second account. With that, he can change the other users groups. Or he could create a new (test) user himself.

I'm closing this as there is no way to do that without creating massive security issues.

So an administrator can update settings of a website but cant change his own group ? sound really crazy

Aside from super users (which can loosely be compared to the root user on a *nix platform), user accounts in general aren't allowed to make changes directly to their own accounts which may result in a privilege escalation, at any level. It doesn't matter if the user is part of the default Registered group (which for the most part has no permissions) or default Administrator group (which has a lot of access to a lot of things), allowing a user to make a modification to their own account's groups changes that account's permissions and can result in a user being allowed to elevate their permission set in an inappropriate way.

The only way to allow a user to modify their own account's groups (and inherently permissions) is if your UI is smart enough to only show options that allows the user to downgrade their active permission set and a core API that is smart enough to check the permissions of every affected asset to ensure the user is not elevating their permissions to any system resource. But that would be a UX issue for the UI things because it would be pretty easy for a user to screw up their own account and a major security and performance issue trying to write code that can scale with our assets configuration to do the depth of checks required to get this right.

So yes, locking it down is the correct approach.

I was not against you guys, i agree the PR, i know the real issue, we cant know wich group is "upper" than other, so using core.admin is actually the fastest best way but wanted to push the idea further !

Well closed