As already mentioned in a comment in https://github.com/WordPress/gutenberg/pull/3378, reusable blocks should have a security concept.
Currently there is none, any user can edit any existing reusable block, even users with contributor role while creating/editing a "pending review" post.
This leads to the weird situation, that a contributor is (as expected) not allowed to publish an own post, but is (unexpected) able to "live edit" sitewide content by editing existing reusable blocks.
WP 4.9.1, Gutenberg 1.9.0
Thanks @tkes. Just pasting some background information on this here for easy reference:
Right now, any user with the edit_posts capability (authors, contributors and editors) can view and edit Reusable Blocks.
We need to let authors insert them, but probably not edit them by default. Not sure if we should let authors create them, or only editors. Furthermore, this is something that should probably be filterable and part of general capabilities so people can map. Example: edit_blocks, insert_blocks, delete_blocks.
A current users with a role below "editor" should only be able to see/create/edit/delete his/her own reusable blocks.
Users with/above "editor" role should be able to see/create/edit/delete any reusable block and also edit its author.
cc. @pento @mtias
I'm inclined to mirror permissions pretty closely to permissions to how each role can act on normal posts.
post_author. There's no draft reusable blocks, so no equivalent for them to be able to create blocks.post_author.post_author for all blocks.It should be fairly straightforward to use the capabilities that we get from registering a custom post type to accomplish this. I've started down this path in https://github.com/WordPress/gutenberg/pull/4031 by specifying a capability_type:
I agree with @pento. One thing we don't have exposed is who the author of a reusable block is. I'd be wary of adding too much UI into them and treat them more like menus, where you don't have to know they are fully fledged posts. cc @jasmussen as it touches on the delete UI a bit. The more we can do from the inserter, the better, in my opinion.
If we are to have more UI for seeing reusable block authors, and a spot to delete them, and it should be in the inserter, my best idea is that we add a "Edit" button to this screen:

Perhaps needs a better label than "Edit", but the button could sit next to the "Saved Blocks" headline, and once clicked it could, for example, make the entire UI for saved blocks into a list that showed author and delete buttons.
Or, hey, we could just skip that edit check and show all reusable blocks in list form, which would free up some room for UI:

It might be good to include the type of the original block as well. Maybe it's time to swap the mosaic icon for the original icon of the block that originated the reusable one?
The inserter is already very complicated, not only for assistive technologies users, but also in terms of cognitive load. I'm not sure adding one more UI related to a completely different functionality would make users life easier. Gutenberg should strive for simplicity. I'd suggest to try an effort to find a simpler solution.
I really like the idea of including an Edit button in the inserter, but I think that it should just link to a full page screen where you can administer your reusable blocks.
Maybe it's time to swap the mosaic icon for the original icon of the block that originated the reusable one?
I agree, it's time 馃暉
Agreed with the above: the icon should represent the type of block. Otherwise, what is the point of having an icon here, its not usable info. I think we are increasingly encountering hierarchy issues in terms of lexicon throughout the project when we address what is happening to this block instance vs this block type. And what is happening to this block vs this block content. For this reason, "edit" as a concept, is too generic. What are we editing? What are we deleting?A user will have a diff impression of edit vs an admin or a dev. I can easily see someone clicking "edit" and thinking they're editing THAT instance rather than that block or vice versa. For this reason, I think we need a completely separate screen for the administration of blocks, generally (because that opens up so many options for plugins) and it keeps the inserter from becoming a trojan horse.
Most helpful comment
I'm inclined to mirror permissions pretty closely to permissions to how each role can act on normal posts.
post_author. There's no draft reusable blocks, so no equivalent for them to be able to create blocks.post_author.post_authorfor all blocks.