Users with "update_plugins" capability can not see update details

[michel.weimerskirch]

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.

[prasoon2211]

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!

[SergeyBiryukov]

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().

[michel.weimerskirch]

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.

[prasoon2211]

@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.

[prasoon2211]

Version 1

[prasoon2211]

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

[SergeyBiryukov]

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.

[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".

[prasoon2211]

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.

[michel.weimerskirch]

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.

[prasoon2211]

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.

[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.

[prasoon2211]

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.

[michel.weimerskirch]

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]

Version 2

[prasoon2211]

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]

Version 3.

[prasoon2211]

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

[prasoon2211]

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

[DrewAPicture]

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.

[jeremyfelt]

I'm seeing this same issue in a slightly different form in multisite.

I've disabled edit_plugins, update_plugins, install_plugins, and upload_plugins for everyone, but manage_network_plugins is still enabled.

I'd like global (super) administrators in our multisite setup to be able to "View version X.Y.Z details" when an update is available. That's usually the cleanest place to see a list of changes before initiating our workflow to upgrade.

There are a couple of things that are getting in the way.

The plugin-install.php page loads wp-admin/network/menu.php when viewed as an iframe, even though no menu is displayed. Because of this a nopriv flag is set when the current user cannot install_plugins.

I can work around this by stomping on the $_wp_submenu_nopriv global to remove that nopriv flag. That's ugly, but so is the menu. :)

Next, a second check for install_plugins caps blocks the actual view in wp-admin/plugin-install.php.

In a nutshell, protecting plugin-install.php with install_plugins caps is only correct when viewing the page through "Add New". In its other forms, there are other protections in place to prevent links for updating/installing from being used.

In 31183.diff​, the cap check is ignored if we're loading the plugin-information tab. This appears to work as expected for me. I haven't fully tested the other scenarios in this ticket yet.