Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#33694 closed defect (bug) (fixed)

Capability missing for editing scheduled posts created by one self (implicit permission bypass)

Reported by: simplebugreporter's profile SimpleBugReporter Owned by: johnbillion's profile johnbillion
Milestone: 4.4 Priority: normal
Severity: normal Version: 2.0
Component: Role/Capability Keywords: ux-feedback 2nd-opinion needs-patch needs-unit-tests
Focuses: administration Cc:

Description

The following capabilities exist today in the Wordpress privilege system:

Edit Posts
Edit Others Posts
Edit Published Posts
Publish Posts

The standard Wordpress role "Contributor" only has the capability "Edit Posts" out of the four above, which in reality translates to "Edit posts only created by one self".

This is good, because editorial staff can then edit the posts before they are published, which is the entire purpose of this role, i.e. a contributor can never publish any content that has not first been vetted by senior staff.

BUT, there is a dangerous logic hole in this permission system right now, which makes it possible for the contributor role to publish arbitrary contents after all!

Namely, when a post created by a "contributor" has been edited by senior staff and subsequently scheduled for publishing (say, in three hours), the permission system apparently still considers the post as both "non-published" and still "owned by its initial creator", i.e. the "contributor" user. Thus, the current permission setup in Wordpress and for the contributor roles does in this situation allow the "contributor" user to freely modify the contents of the post, and subsequently thus have these arbitrary modifications published on the pre-scheduled moment in time.

In addition to the fact that scheduled posts most of the time won't be re-visited by the editorial staff before being published (thus giving lots of time for the original "contributor" user to edit them even without any malicious intent), this can also be exploited with explicit malice by such a "contributor" user, by purposely making the desired edits to the post, say, five seconds before the scheduled publishing time, thereby having these new contents published instantly thereafter, before any members of the editorial staff has had any chance to vet these changes, or most of the time even know of them.

There are two possible simple solutions to this problem, out of which I therefore suggest you choose one for implementation as soon as possible:

1.
Make the permission system consider scheduled posts as "Published" already from the moment they are scheduled, thus blocking any edits of them given already today's alotted capabilities in Wordpress for the "contributor" role.

2.
Add a new capability to the permission system called "Edit Scheduled Posts", which the "contributor" role does NOT have by default, therefore blocking this role from editing scheduled posts, EVEN if they are originally created by the "contributor" user in question.

Change History (8)

#1 @juliobox
9 years ago

Hello

Solution 3:
If a scheduled post is modified, change its status as "pending" again.

#2 @juliobox
9 years ago

  • Version changed from 4.3 to 2.0

#3 @johnbillion
9 years ago

  • Keywords ux-feedback 2nd-opinion needs-patch needs-unit-tests added

I like Juliobox's suggestion.

#4 @johnbillion
9 years ago

  • Owner set to johnbillion
  • Resolution set to fixed
  • Status changed from new to closed

In 35747:

When a post is scheduled for publication, treat it the same as a published post when calculating the capabilities required to edit or delete it.

Fixes #33694

#5 @helen
9 years ago

  • Milestone changed from Awaiting Review to 4.4

#6 @shellghost
9 years ago

Hi,

Is there a way to revert this change without editing the core?

Our site was built around this functionality, of allowing authors to edit scheduled posts but not published posts.

#7 @DrewAPicture
9 years ago

Hi @shellghost, you can still modify this behavior using the map_meta_cap filter to adjust caps based on the status of the passed object and the role of the current user.

#8 @johnbillion
8 years ago

#21644 was marked as a duplicate.

Note: See TracTickets for help on using tickets.