I can confirm this default Joomla behavior.

The visibility/access to component options is controlled by the action "core.admin".

The visibility/access to permissions (component, category, article, module, etc..) is controlled by the action "core.admin".

Solution 1

Solution 1 won't be my preferred option, as there are cases where you want to allow a user group to configure there permissions, also their own group permissions. Also thinking in line of levels like manager/administrator is not the correct approach, forget about that, its Joomla 1.5. Levels above don't necessary mean more possibilities/actions allowed.

Solution 2

Solution 2 is the only way to go if we want people to allow to configure component options without configuring permissions. A new core action like "core.permissions" for global configuration and components would be a possible solution. A change like this will have impact for sure.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4954.

The more I think about it we need to have a mix of the two solutions

We need to allow people to edit to configure component options without configuring permissions

We need to prevent someone changing their own ACL permissions. Otherwise what is the point in setting that someone can only Edit Own if they can go in and change it


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4954.

I think it would make sense to add a separate check for the permissions.

I don't think it makes much sense to restrict to which groups you can set the ACL. If someone can edit ACL, he could do all sort of things anyway. It wouldn't be enough to restrict him from editing his own group. He could create new groups, elevate existing groups (like registered) and use those instead.
So we would need a way to prevent him from raising any group above his own levels, but since the permissions itself (edit, edit,own, create, ...) aren't set up hierarchic, this could become tricky.
You could probably check each setting if the user has valid permissions for that setting himself, making an access check for each setting he tries to change.

I'd say just don't give anyone the permission to edit the ACL except the admins. With Solution 2, that would be possible and probably would solve the issue. Or is there a use case where a user needs to be able to edit ACL without having admin permissions on the extension?
We just need to find a way that is backward compatible for extensions which don't have that ACL configured. Like checking if core.permissions exists and if not fall back to core.admin.

I dont believe you should ever be able to change your own acl setting
(unless you are a super user). So any solution that stops that is essential.

Note this applies to all components. So I might already deny a user access
to the users component so they cannot create new groups and levels but if
they have access to the content component they can change the permisssions
for that, that were assigned to them

On 29 October 2014 15:09, Thomas Hunziker notifications@github.com wrote:

I think it would make sense to add a separate check for the permissions.

I don't think it makes much sense to restrict to which groups you can set
the ACL. If someone can edit ACL, he could do all sort of things anyway. It
wouldn't be enough to restrict him from editing his own group. He could
create new groups, elevate existing groups (like registered) and use those
instead.
So we would need a way to prevent him from raising any group above his own
levels, but since the permissions itself (edit, edit,own, create, ...)
aren't set up hierarchic, this could become tricky.
You could probably check each setting if the user has valid permissions
for that setting himself, making an access check for each setting he tries
to change.

I'd say just don't give anyone the permission to edit the ACL except the
admins. With Solution 2, that would be possible and probably would solve
the issue. Or is there a use case where a user needs to be able to edit ACL
without having admin permissions on the extension?
We just need to find a way that is backward compatible for extensions
which don't have that ACL configured. Like checking if core.permissions
exists and if not fall back to core.admin.

—
Reply to this email directly or view it on GitHub
#4954 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I dont believe you should ever be able to change your own acl setting

I agree with that in theory.
In practice I'm still curious what the use case is where you would need someone to give access to ACL who is restricted otherwise. Like he can only edit his own articles but needs access to ACL.

Currently, we don't allow an admin to set himself to super admin. Which is the only way he could raise his own permissions any further.

By the way: Our ACL doesn't allow to set someone allowed for editing ACL/options but restricting him otherwise. It will set all other ACL settings to allowed as well.

this is the problem. If you allow someone to set options then they can set
acl.
I might want them to be able to set options but not change their ACL

You cannot do that - that is a big problem

On 29 October 2014 15:21, Thomas Hunziker notifications@github.com wrote:

By the way: Our ACL doesn't allow to set someone allowed for editing
ACL/options but restricting him otherwise. It will set all other ACL
settings to allowed as well.

—
Reply to this email directly or view it on GitHub
#4954 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I agree with that fully and I see the use case for that. This is what would be solved with the additonal core.permissions check suggested by Sander in his second solution.
The only drawback would be that it only would work for extension which have it implemented.

Have a look at #4975. That should hopefully solve it in a full B/C way.