Opened 10 years ago
Last modified 7 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, multisite | 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 (4)
Change History (25)
#1
@
10 years ago
- Component changed from Role/Capability to Plugins
- Focuses administration added
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 4.2
#3
in reply to:
↑ 2
@
10 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 notinstall_plugin
It's possible to add a role with custom capabilities that would have update_plugins
, but not install_plugins
. See add_role().
#4
@
10 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:
↓ 8
@
10 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. 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:
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.
#6
@
10 years ago
@SergeyBiryukov: I have uploaded a patch. Running the test suite, I did't get any errors. Would this work?
This ticket was mentioned in Slack in #core by prasoon2211. View the logs.
10 years ago
#8
in reply to:
↑ 5
@
10 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:
↓ 10
@
10 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".
#10
in reply to:
↑ 9
@
10 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
@
10 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
@
10 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
@
10 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
@
10 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
@
10 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.
#16
@
10 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.
#17
@
10 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
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#20
@
10 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.
#21
@
7 years ago
- Focuses multisite added
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.
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 notinstall_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!