WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#31183 new defect (bug)

Users with "update_plugins" capability can not see update details

Reported by: michel.weimerskirch Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.1
Component: Plugins Keywords: has-patch
Focuses: administration Cc:

Description

Users with the "update_plugins" capability can see available updates for plugins, but see the message "You do not have sufficient permissions" when clicking on "View version x.y.z details", because that page requires the "install_plugins" capability. The details page (with changelog, etc) should also be available with only the "update_plugins" capability.

Attachments (3)

31183.diff (1.3 KB) - added by prasoon2211 3 years ago.
Version 1
31183.2.diff (1.5 KB) - added by prasoon2211 3 years ago.
Version 2
31183.version3.diff (1.4 KB) - added by prasoon2211 3 years ago.
Version 3.

Download all attachments as: .zip

Change History (23)

#1 @SergeyBiryukov
3 years ago

  • Component changed from Role/Capability to Plugins
  • Focuses administration added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.2

#2 follow-up: @prasoon2211
3 years ago

Hey @michel.weimerskirch

There seems to be some problem with your report. According to this page: http://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table, there are no such roles which can only update_plugin but not install_plugin and so, this behaviour should not happen (Right now, a super admin as well as an administrator can both update and install plugins). This would mean that either the bug has been fixed in the development version or that there is a discrepancy in the documentation of Roles and Capabilities.

Can you tell your what role is this error occurring for? Thanks!

#3 in reply to: ↑ 2 @SergeyBiryukov
3 years ago

Replying to prasoon2211:

According to this page: http://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table, there are no such roles which can only update_plugin but not install_plugin

It's possible to add a role with custom capabilities that would have update_plugins, but not install_plugins. See add_role().

#4 @michel.weimerskirch
3 years ago

Yes, I created a custom role that can handle updates but not install new plugins. I should have made that clearer in my initial report.

#5 follow-up: @prasoon2211
3 years ago

@SergeyBiryukov: Well, I didn't know about custom roles so thanks for letting me know :)

Anyway, while I was investigating this issue, I thought of removing the install_plugins capability from an administrator for testing. So, I used remove_cap on the admin user (not a role but a WP_User). But, the capability didn't get removed. So, I opened up a debugger to see what was happening inside the remove_cap method and there seems to be a problem in it. See this debugging screenshot: http://picpaste.com/pics/remove_cap-ubXz63Nz.1423056638.png

On the left pane is the remove_cap function which checks for the capability to remove under the $this->caps variable when it should (I think) check in $this->allcaps (see local vars in the right pane).

Should I file a bug for this or is this expected behaviour? Also, if this is expected behaviour, how would I go about removing a capability from a user (since remove_cap doesn't seem to be working in this case)?

Thanks!

Edit: Just checked changing $this->caps to $this->allcaps to no avail. The capability still didn't get removed. So how do I remove install_plugin capability from a user? For the time being, I'll just create a new role to do the testing but I should be able to change the capabilities of just a single user, too.

Last edited 3 years ago by prasoon2211 (previous) (diff)

@prasoon2211
3 years ago

Version 1

#6 @prasoon2211
3 years ago

@SergeyBiryukov: I have uploaded a patch. Running the test suite, I did't get any errors. Would this work?

Last edited 3 years ago by prasoon2211 (previous) (diff)

This ticket was mentioned in Slack in #core by prasoon2211. View the logs.


3 years ago

#8 in reply to: ↑ 5 @SergeyBiryukov
3 years ago

  • Keywords has-patch added; needs-patch removed

Replying to prasoon2211:

Should I file a bug for this or is this expected behaviour? Also, if this is expected behaviour, how would I go about removing a capability from a user (since remove_cap doesn't seem to be working in this case)?

Not sure about the remove_cap() bug you've encountered, but 'map_meta_cap' filter works for me:

function wp31183_remove_install_plugins_capability( $caps, $cap, $user_id, $args ) {
	if ( 'install_plugins' === $cap ) {
		$caps[] = 'do_not_allow';
	}

	return $caps;
}
add_filter( 'map_meta_cap', 'wp31183_remove_install_plugins_capability', 10, 4 );

I've tested 31183.diff, and it fixes the issue. Would like a second look from another committer.

#9 follow-up: @michel.weimerskirch
3 years ago

The patch does not work for me. I have to add the "activate_plugin" capability to the user as well for them to be able to access the changelog.

A way to solve this would be to make it similar to the user-related capabilities (list_users, create_users, etc) add an additional more neutral capability "list_plugins".

Last edited 3 years ago by michel.weimerskirch (previous) (diff)

#10 in reply to: ↑ 9 @prasoon2211
3 years ago

Replying to michel.weimerskirch:

The patch does not work for me. I have to add the "activate_plugin" capability to the user as well for them to be able to access the changelog.

A way to solve this would be to make it similar to the user-related capabilities (list_users, create_users, etc) add an additional more neutral capability "list_plugins".

According to the docs http://codex.wordpress.org/Roles_and_Capabilities#activate_plugins, the user must be able to activate_plugins in order to gain access to the plugins panel and so, this is expected behaviour, IMHO. I just checked - if activate_plugins is disabled, plugins tab is not accessible and outputs an error message.

#11 @michel.weimerskirch
3 years ago

But the update page (wp-admin/update-core.php) is available with the update_plugins capability. Plugins can be updated correctly (without the possibility to install new plugins of course). Only the changelogs link on that page leads to an "access denied" error.

#12 @prasoon2211
3 years ago

I didn't know about the update-core.php page before but I just checked now - the viewing of changelogs is working on this page as well.

Here are a couple of screenshots. I have disabled both activate_plugins and install_plugins and even then, the patch works.

User permissions: http://picpaste.com/s1-oXaZ0Zee.png
Update page: http://picpaste.com/s2-Oml42Skn.png
Changelog: http://picpaste.com/s3-0xty6Dmr.png

Please try to apply the patch again and check.

#13 @michel.weimerskirch
3 years ago

Yes, with the additional "activate_plugins" capability in addition to the "update_plugins" capability, the changelogs can be accessed.

IMHO the update_plugins capability should suffice though, but I suppose that's more complicated to achieve.

#14 @prasoon2211
3 years ago

Replying to michel.weimerskirch:

Yes, with the additional "activate_plugins" capability in addition to the "update_plugins" capability, the changelogs can be accessed.

IMHO the update_plugins capability should suffice though, but I suppose that's more complicated to achieve.

In my last comment (12), I explicitly mentioned that activate_plugins was not required. And yes, simply having update_plugins enabled works - there's no need for activate_plugins to be enabled. (Look at the attached screenshots in 12 please). Please let me know if you're still having problems.

#15 @michel.weimerskirch
3 years ago

I tried again. I still get the access denied error:
Capabilities: http://picpaste.com/capabilities-AO0lxpOy.png
Update page with changelog: http://picpaste.com/update-page-hV2boiJW.png

The problem seems to be that in menu.php, "plugins.php" requires the "activate_plugins" option: $submenu['plugins.php'][5] = array( __('Installed Plugins'), 'activate_plugins', 'plugins.php' ); and plugin-install.php (which contains the update information) is a subpage of plugins.php:
$submenu['plugins.php'][10] = array( _x('Add New', 'plugin'), 'update_plugins', 'plugin-install.php' );

Because of that, plugin-install.php also requires the "activate_plugins" capability.

@prasoon2211
3 years ago

Version 2

#16 @prasoon2211
3 years ago

Okay I discovered the problem. You need to enable edit_plugins for this to work. But, you don't need activate_plugins enabled. Check out this screenshot for permissions: http://picpaste.com/capabilities-IVTbT2et.png

So, now the question is this: Do we need to remove the check for edit_plugins as well? Right now, we're allowing the user to have upload_plugins enabled. So, they are technically editing the installed plugins, IMO. So it is reasonable to assume that edit_plugins needs to be enabled along with update_plugins.

Anyway, I'm attaching the fix for this as well.

@prasoon2211
3 years ago

Version 3.

#17 @prasoon2211
3 years ago

The only problem with the version_2 patch I submitted is that there is the added menu option for plugins in the left navigation bar. This menu contains two submenus, 1. Add new and 2. Edit plugins.

Of course, the user isn't allowed to do either (install_plugins and edit_plugins are disabled) and the user is left with a "not allowed" warning when he opens these links. But, ideally, these options shouldn't even be shown.

For this, I've uploaded a version 3 which solves all problems mentioned. I've also ran the tests for this version and all the tests are passing. So, I suppose that this version (version 3) works the best.

Please test this, @michel.weimerskirch, @SergeyBiryukov

#18 @prasoon2211
3 years ago

Hi again guys. Just a reminder to test the version_3 of the patch.

This ticket was mentioned in Slack in #core by drew. View the logs.


3 years ago

#20 @DrewAPicture
3 years ago

  • Milestone changed from 4.2 to Future Release

I think we need a clearer picture of which capabilities are need for the various update vs view changelog vs install actions. Right now, none of the patches here fully address the original concern of being able to view the changelog.

What would be helpful here is snippet of code enabling testers to directly reproduce the problem and a patch that addresses it. Pushing to a future release.

Note: See TracTickets for help on using tickets.