[wp-trac] [WordPress Trac] #16956: Comments Being Pulled from Non-Existent Post Types

[WordPress Trac]

#16956: Comments Being Pulled from Non-Existent Post Types
-------------------------------------------------+-------------------------
 Reporter:  sterlo                               |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Posts, Post Types                    |  Release
 Severity:  normal                               |     Version:  3.1
 Keywords:  has-patch 2nd-opinion needs-unit-    |  Resolution:
  tests                                          |     Focuses:
-------------------------------------------------+-------------------------

Comment (by jorbin):

 Replying to [comment:38 boonebgorges]:
 > > I have some concerns that this could lead to unexpected capability
 escalation
 >
 > Are your concerns related to a general squeamishness about cap mapping,
 or are you imagining specific scenarios where escalation could occur? I'm
 struggling to describe a situation where meaningful cap escalation could
 take place. There is perhaps a concern that a plugin registers a post type
 'foo' and provides custom logic for, eg, 'edit_foo'; when the plugin is
 then deactivated, the WP interface will fall back on 'edit_post'; and
 while currently `current_user_can( 'edit_post' )` will always return false
 in these cases, with my proposed fix it will obey the general logic for
 'edit_post'. I can imagine cases where this might be problematic, but I'm
 also not sure how much WP can be responsible for it, given that caps are
 registered and processed at runtime.

 Mostly general squermishness and paranoia.  I think my worry is something
 like:

 Developer creates a CPT with custom capabilities and maps it so that only
 users who's name starts with the letter A can manage comments (since A
 names are awesome).  A user with a name starting with B has the ability to
 deactivate plugins and deactivates the plugin containing this CPT.  With
 this change, they would now be able manage comments even though they don't
 have an awesome A name.

 Over paranoid?  Very possible. At a minimum, I think we should throw a
 doing_it_wrong with some instructions so that developers are less likely
 to accidentally escalate privileges here.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/16956#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform