Greeting all...

First of all, thank you Joomlaworks for providing us so useful and wonderful extension K2 for free. It is great!

Ok, I just have found a problem which could cause a threat to our site, where user with very limited backend admin access can see, and take action on things they suppose NOT to do. I spent last few days on testing this issue in both local server and also online server. I can confirm this is really potential problem which can destroy the whole K2 articles in our site. To make it short, let's make it this way:

1. Fresh install Joomla 3.8.5.
2. Fresh install K2.
3. No other extension installed.
4. I (as Super User) create Joomla usergroup Author, and new Viewing Access Level called "Author" which includes Public, Registered and Author only (ticked).
5. I create a Joomla user named "author1" which will act as article creator. In Joomla user, I assign this user author1 to usergroup Author. Then import the user to K2 user. His ONLY job is to create K2 articles and edit his OWN articles when necessary via back end and NOT to publish it. To do so, I assign his permission via Joomla ACL as follow :

• Joomla global ACL, set the group Author to have backend Administrator login. That's it. The rest permission in this point is inherited.
• Still in Global Configuration, go to K2 permission tab. Set Author permission to allow CREATE and EDIT OWN. *I also have to set Access Administration Interface" to Allowed, in order to make the admin menu toolbar appear to the author while he is login to backend administrator. Otherwise he will not be able to access either component toolbar or any K2 section (panel) in backend administrator.* Save it.
• Go to admin menu Joomla Extension --> Modules --> Administrator. FInd the module "Toolbar", edit it and grant access to "Author"

If we do it correctly, we can now logout as Super User, and re-login to backend administrator as Author1 with limited view access.

What we see as Author1 in backend administrator Cpanel page is K2 stats (admin) , and K2 Quick Icons (admin) , while in toolbar he can see Components and Help menu. The Components will only have K2 sub menu, * with K2 FULL sub menu instead of only Items, category, tags, comments, media manager, and information! *

That means, using the toolbar this Author1 is able to access many unauthorized resources and take unauthorized action such as disabling any user available (despite their usergroup), and flag them as spammer!

It is true that when he tries to access (for example) the K2 Users page, he will be warned by red error box saying "Error you are not authorized to view this resource", but still the page is open and give him an access to many unauthorized option to take action such as disabling users, and flag users as spammers.

Ok, so what if I don't grant access of module toolbar to Author? Doesn't that mean he is still able to access K2 section via K2 Quick Icons (admin) menu in Cpanel when he logged in and NOT having full K2 menu in toolbar?

Yes... He will not see Component menu in toolbar. Thus he wont have any K2 submenu either. And he still be able to access K2 backend section through K2 Quick Icons (admin). The problem is, there is still a chance for him to easily "sneak" into the hole.

Let's say I don't grant access of module toolbar to Author in admin menu module. This author can access K2 backend section through K2 Quick Icons (admin). What he will see in the left menu are : Items, Categories, Tags, Comments, Media Manager, and Information only. No link to K2, Users, Usergroups, or Extra fields. The problem is, when he create new article (or editing his own) the K2 item editor will open. In this K2 item editor, he CAN change the author by clicking Author button... When he click it, K2 users page will open and again, he will be warned by red error box saying "Error you are not authorized to view this resource", but still the page is open and give him an access to many unauthorized option to take action such as disabling users, and flag users as spammers.



If you don't have any idea what was happening when someone click flag users as spammer to legit site contributors, it is big disaster. All their articles will be destroyed from database, and the user is deleted from K2 database table, the site turns out error 1056 database error etc in front end, etc... Well, at least that was what happen to me last week. The website down for a while. Lucky I got daily backup to restore (Thanks Akeeba!).

I am not sure if this is appropriate, but granting this user "Access Administration Interface" in global K2 permission ACL should not go that far. There should be a way where "Access Administration Interface" permission does not give him way to far access in K2 admin section. Instead, only permission given to him is accessible (like create items and edit his own).


The next thing is, he is able to publish his own article if he manage to edit his own article via backend admin K2 item editor. It is true, that if he goes to Items menu in K2, (where he will see list of articles), he can not click (un-tick) the published checkbox (doing so will not change the state of article) to make it published or unpublished. But if he manage to edit the articles, he is able to change the state of publishing via K2 item editor page (it will take effect after saving).


That's all for now, please bear my English. I hope JW developers can take a look into the problem and solve them in next release.

Thank you so much for all your effort! You guys ROCK!!

Thank yo so much for reporting this.
We will investigate and let you know.

Thank you Krikor and Fotis for replying.

Fotis wrote: In order for an editor in the backend to have access to users, extra fields etc. they MUST have "core.admin" rights assigned to them. In other words, they must share a critical feature available to admins only.

If your plain user can modify content beyond items and categories and comments, make sure they don't have the above permissions when configuring their group.

If you mean by "core.admin" rights is what we have with Joomla ACL as Global Configuration --> Permission --> Author, then I believe I have not assigned them "Access Administration Interface" . But if you mean K2 ACL permission, then I do assign the Author "Access Administration Interface" in K2 ACL permission. Because if I don't assign them in Access Administration Interface of K2 ACL permission, he can not access K2 at back end administrator page at all.

The most simple yet logic solution that comes to my mind is to disable (or hide) the "change author" button and publishing state in K2 item editor for user without publishing right like we have on front end site editor. Well, at least that would prevent the user to "sneak into the hole".

Thank you. :-)

Fotis wrote: Can you post a screenshot of the K2 "Permissions" tab please?

This is how I set Joomla Global Configuration permission to the group Author, and K2 permission.

Fotis wrote: Actually, see this: docs.joomla.org/J3.x:Access_Control_List_Tutorial

Scroll down to the "Manager" screenshot: docs.joomla.org/J3.x:Access_Control_List_Tutorial#/media/File:Screenshot_global_acl_manager_J3_tutorial-en.png

This is how you want your ACL setup in K2 so Joomla backend users can simply post content in K2. The K2 user group permissions relate to the frontend editing features only.

In your case, you could just add new editors to the "Managers" group and they'll only access content in K2 that should be accessed from regular content editors (items, categories, comments and media manager).

Yes, I read the tutorial and I think I understand how it should work ideally. However sir, in this case, I think the K2 "Access Administration Interface" has gone too far by giving user ability to also disabling user and flagging as spammer, as wel as giving him ability to publish items through K2 item editor (in this case it means breaking the "Edit State" in K2 permission which is set to Not Allowed).

If you try to test it, you might understand what I'm concern here.

Thank you so much for all your effort sir.

I hope to hear some good news or notes from developers regarding this issue. Thank you. :-)

I have the exact same issue. I have some users that are editors and are supposed to just be able to save as draft, but they can edit the articles and change the publish state and it overrites the permissions. If they try and change the article state in the items list, it gives an error (as it is supposed to):

Error
You are not authorised to view this resource.

But if you edit the item you can change the publish state just fine.

I'm not sure if this is a bug, but could the same logic not be applied at article save level?