Creo que he encontrado la respuesta autorizada, ayudada en gran medida por la tabla proporcionada en este artículo: http://msdn.microsoft.com/en-us/library/ms178569.aspx . Parece que CREATE DATABASE es de hecho el permiso ANSI SQL, mientras que CREATE CUALQUIER BASE DE DATOS es un permiso de servidor propietario de MSSQL. Sin embargo, los dos no son lo mismo. De hecho, hay una distinción bastante importante entre los dos, y lo descubrí al intentarlo.
Ambos son permisos, pero CREATE DATABASE solo consulta el contexto de seguridad de la base de datos utilizada actualmente, mientras que CREATE CUALQUIER BASE DE DATOS puede buscar la lista de inicios de sesión en SQL Server. Esto parece implementarse porque la expectativa general para un servidor ANSI SQL es que los permisos se otorgan en alguna base de datos del sistema principal, y los usuarios de esa base de datos reciben permisos. Entonces, el comportamiento predeterminado de las nuevas bases de datos es consultar al maestro para ver qué permisos debe heredar. (SQL 101, lo sé, pero realmente se ejemplifica aquí).
Por lo tanto, cuando otorga CREATE DATABASE, debe tener un usuario maestro para otorgar este permiso. Si intenta esto, funciona (cree un usuario en maestro, concédale crear una base de datos, luego puede crear bases de datos). Sin embargo, al otorgar la creación de cualquier base de datos (o al otorgar el rol dbcreator), no necesita ser un usuario literal en master.
Para ilustrar aún más la diferencia entre los dos permisos, observe los diferentes mensajes devueltos al otorgar a un usuario CREAR BASE DE DATOS en el maestro frente a otra base de datos, luego enjuague y repita para obtener el permiso CREAR CUALQUIER BASE DE DATOS.
use master; GRANT CREATE DATABASE to TestUser
Mensaje 15151, Nivel 16, Estado 1, Línea 1 No se puede encontrar el usuario 'TestUser', porque no existe o no tiene permiso.
Este error ocurre porque el usuario TestUser aún no está en la base de datos maestra. Este es un permiso de nivel de base de datos: no tiene contexto para salir de la base de datos seleccionada y buscar inicios de sesión o usuarios. Tenga en cuenta que si primero crea el usuario en maestro, este comando tiene éxito y puede crear bases de datos como si se le hubiera otorgado CREAR CUALQUIER BASE DE DATOS.
use master; GRANT CREATE ANY DATABASE to TestUser
Comando (s) completado con éxito.
Esto tiene éxito porque, como un permiso propietario de Microsoft SQL Server, CREATE CUALQUIER BASE DE DATOS puede consultar la lista de inicios de sesión para la instancia de SQL, no solo los usuarios de la base de datos utilizada actualmente.
use test; GRANT CREATE DATABASE to TestUser
Mensaje 15151, Nivel 16, Estado 1, Línea 1 No se puede encontrar el usuario 'TestUser', porque no existe o no tiene permiso.
Esto demuestra la coherencia de mi explicación para el primer ejemplo. Tenga en cuenta la consulta a continuación y su mensaje de error resultante. No recibirá este mensaje de error si primero crea el usuario en esta base de datos (consulte la última consulta).
use test; GRANT CREATE ANY DATABASE to TestUser
Msg 4621, Nivel 16, Estado 10, Línea 1 Los permisos en el ámbito del servidor solo se pueden otorgar cuando la base de datos actual es maestra
Como se muestra en la segunda consulta, CREATE ANY DATABASE consulta la lista de inicios de sesión, donde ya había creado este nombre de usuario. Entonces, si bien SQL Server reconoció la existencia del usuario, todavía se produce un error porque estoy tratando de otorgar un permiso de nivel de servidor en otro lugar que no sea maestro, que no está permitido en MSSQL.
use test; create user TestUser; grant create database to TestUser
El permiso CREATE DATABASE solo se puede otorgar en la base de datos maestra. Mensaje 0, Nivel 11, Estado 0, Línea 0 Se produjo un error grave en el comando actual. Los resultados, si los hay, deben descartarse.
Ahora que hay un usuario para que CREATE DATABASE se aplique, recibo el mensaje de error genérico de que no puede otorgar permisos a nivel de servidor en ningún lugar que no sea maestro, porque allí es donde SQL Server almacena estos permisos.
Bueno, esto fue divertido.