Room alias consumed when user blocked from publishing a newly-created room

[AndrewFerr]

Description

If Synapse is configured to allow a user to create local room aliases but not publish rooms, then whenever that user attempts to publish a new room with a custom local alias, the room creation will be blocked, as expected.

The problem is that although the room creation is blocked, the creation of the alias is not: the alias remains bound to the room ID that would have been assigned to the room, had its creation not been blocked.

This has the effect of the alias being unavailable for other rooms, with most clients not offering a way to free it (since the alias isn't bound to a valid room).

A workaround is to make a direct call to DELETE /_matrix/client/r0/directory/room/{roomAlias}.

Steps to reproduce

• In Synapse, apply these config settings:
  • Set alias_creation_rules to allow for all users
  • Set room_list_publication_rules to deny for a specific user
• From any client, use the denied user to send /createRoom with "visibility": "public" and "room_alias_name": <some_custom_alias>. An easy way to do this is to create a new public room in Element Web, which enforces new public rooms to be published & to have aliases.
• Get a 403 response from Synapse. If using Element Web, get a message of "Server may be unavailable, overloaded, or you hit a bug."
• Try to create the same room again, but with a different user that has permission to publish rooms

Attempts to use the same alias for the new room will fail, since the alias is still in use for the room that failed to be created. Element Web will say "This address is already in use" when typing the alias in the "Room address" section of the "Create a public room" dialog.

Version information

• Homeserver: Testbench homeserver on localhost

• Version: 1.43.0 (b=develop,d37841787)

• Install method: git clone

• Platform: Fedora 34 Workstation