Usar EXECUTE AS en módulos
EXECUTE AS se puede utilizar para definir el contexto de ejecución de los siguientes módulos definidos por el usuario: funciones, procedimientos, colas y desencadenadores. Por ejemplo, es posible cambiar el contexto de ejecución del llamador del módulo al de su propietario o al de un usuario específico. En versiones anteriores de SQL Server, estos módulos siempre se ejecutan en el contexto del llamador del módulo.
Al especificar el contexto en el que se ejecuta el módulo, se puede controlar la cuenta de usuario que el SQL Server 2005 Database Engine (Motor de base de datos de SQL Server 2005) utiliza para validar los permisos en los objetos a los que el módulo haga referencia. De esta forma se dispone de mayor control y flexibilidad para administrar los permisos a lo largo de la cadena de objetos que existe entre los módulos definidos por el usuario y los objetos a los que esos módulos hacen referencia. Los usuarios del módulo sólo necesitan permisos para ejecutar el propio módulo; no se requieren permisos explicitos en los objetos a los que se hace referencia. Sólo el usuario en cuyo nombre se ejecuta el módulo debe tener permisos en los objetos a los que el módulo tiene acceso.
EXECUTE AS CALLER
EXECUTE AS CALLER especifica que las instrucciones incluidas en el módulo se ejecutan en el contexto del llamador del módulo.
EXECUTE AS CALLER se utiliza en los siguientes casos:
- Se desea que las instrucciones del módulo se ejecuten en nombre del usuario que realiza la llamada.
- Se desea comprobar los permisos que posee para las instrucciones del módulo el usuario que realiza la llamada y confiar sólo en el encadenamiento de propiedad para omitir las comprobaciones de permisos en los objetos subyacentes. Recuerde que el encadenamiento de propiedad sólo se aplica a las instrucciones DML. Para obtener más información acerca del encadenamiento de propiedad, vea Cadenas de propiedad.
- La aplicación no requiere que se oculten al usuario los objetos subyacentes a los que se hace referencia o sólo se hace referencia a objetos de la misma propiedad y, por tanto, se confía en el encadenamiento de propiedad para ocultar el esquema.
- Se desea mantener el comportamiento de SQL Server 2000.
Escenario de EXECUTE AS CALLER
Mary crea un procedimiento almacenado que hace referencia a una tabla que no posee pero para la que tiene permiso SELECT. Especifica EXECUTE AS CALLER en la instrucción CREATE PROCEDURE, como se muestra en este ejemplo:
CREATE PROCEDURE AccessTable
WITH EXECUTE AS CALLER
AS SELECT * FROM dbo.SomeTable;
Después, Mary concede el permiso EXECUTE a Scott para el procedimiento almacenado. Cuando Scott ejecuta el procedimiento almacenado, el Database Engine (Motor de base de datos) comprueba si éste, el llamador, tiene permiso para ejecutarlo. Scott tiene el permiso EXECUTE, pero, como Mary no es la propietaria de la tabla a la que se hace referencia, el Database Engine (Motor de base de datos) comprueba si Scott tiene permisos en la tabla. Si Scott no tiene permisos, se produce un error en la instrucción del procedimiento almacenado.
EXECUTE AS user_name
EXECUTE AS user_name especifica que las instrucciones incluidas en el módulo se ejecuten en el contexto del usuario especificado en user_name.
EXECUTE AS user_name se utiliza en los siguientes casos:
Se desea que las instrucciones del módulo se ejecuten en el contexto de un usuario especificado.
No se puede confiar en el encadenamiento de propiedad para ocultar el esquema subyacente (porque, por ejemplo, el módulo tiene acceso a los objetos con una propiedad diferente) y no se desea conceder permisos para esos objetos a los que se hace referencia.
Se desea crear un conjunto de permisos personalizado. Por ejemplo, se desea proporcionar permisos para operaciones DDL para las que normalmente no se pueden conceder permisos específicos. Para obtener más información, vea Usar EXECUTE AS para crear conjuntos de permisos personalizados.
[!NOTA] Un usuario que se especifica como el contexto de ejecución de un módulo no se puede quitar hasta que no se cambie el contexto de ejecución de ese módulo.
Escenario de EXECUTE AS user_name
Mary crea un procedimiento almacenado que hace referencia a una tabla que no posee pero para la que tiene permisos SELECT. Especifica EXECUTE AS 'Mary' en la instrucción CREATE PROCEDURE, como se muestra en este ejemplo:
CREATE PROCEDURE AccessMyTable
WITH EXECUTE AS 'Mary'
AS SELECT * FROM dbo.MyTable;
Mary concede el permiso EXECUTE a Scott para el procedimiento almacenado. Cuando Scott ejecuta el procedimiento almacenado, el Database Engine (Motor de base de datos) comprueba si éste tiene permiso para ejecutarlo; sin embargo, se comprueba si es Mary la que tiene permisos para la tabla a la que se hace referencia. En este escenario, aunque Scott no tiene permisos SELECT para la tabla directamente, puede tener acceso a los datos a través del procedimiento, porque Mary, en cuyo contexto se ejecuta el procedimiento, tiene permisos de acceso a los datos de la tabla.
EXECUTE AS SELF
EXECUTE AS SELF es equivalente a EXECUTE AS user_name, pero el usuario especificado es la persona que crea o modifica el módulo.
EXECUTE AS SELF se utiliza en los siguientes casos:
- Desea disponer de un acceso directo para especificarse a sí mismo como el usuario en cuyo contexto desea que se ejecuten las instrucciones del módulo que va a crear o modificar.
- Dispone de una aplicación que crea módulos para los usuarios que realizan llamadas en ella y desea que esos módulos se creen utilizando a esos usuarios como el contexto de ejecución. En este escenario, se desconoce, en tiempo de diseño, el nombre del usuario que realiza la llamada.
EXECUTE AS OWNER
EXECUTE AS OWNER especifica que las instrucciones incluidas en el módulo se ejecuten en el contexto del propietario actual del módulo. Si el módulo no tiene un propietario específico, se utiliza el propietario del esquema del módulo.
EXECUTE AS OWNER se utiliza en el caso siguiente:
- Se desea poder cambiar el propietario del módulo sin tener que modificar el propio módulo. En otras palabras, OWNER se asigna automáticamente al propietario actual del módulo en tiempo de ejecución.
OWNER es el propietario explícito del módulo o, si no hay ningún propietario explícito, el propietario del esquema del módulo en el momento en que se ejecuta. OWNER debe ser una cuenta singleton y no un grupo ni una función. La propiedad del módulo no se puede cambiar a un grupo o a una función cuando el módulo especifica EXECUTE AS OWNER y tiene un propietario explícito. La propiedad de un esquema no se puede cambiar a una función o a un grupo cuando contiene un módulo que especifica EXECUTE AS OWNER y los módulos no tienen un propietario explícito.
Escenario de EXECUTE AS OWNER
Mary crea un procedimiento almacenado que hace referencia a una tabla que le pertenece. Especifica EXECUTE AS OWNER en la instrucción CREATE PROCEDURE, como se muestra en este ejemplo:
CREATE PROCEDURE Mary.AccessMyTable
WITH EXECUTE AS OWNER
AS SELECT * FROM Mary.MyTable;
Mary concede el permiso EXECUTE a Scott para el procedimiento almacenado. Cuando Scott ejecuta el procedimiento almacenado, el Database Engine (Motor de base de datos) comprueba si éste tiene permiso para ejecutarlo; sin embargo, se comprueba si es Mary la que tiene permisos para la tabla a la que se hace referencia porque es ella la actual propietaria del procedimiento. Mary decide dejar la compañía y pasa la propiedad del procedimiento y la tabla a Tom. Cuando Scott ejecuta el procedimiento almacenado después del cambio de propiedad, todavía puede tener acceso a los datos a través del procedimiento almacenado, porque OWNER se asigna automáticamente a Tom.
Vea también
Conceptos
Otros recursos
Cambio de contexto
EXECUTE AS (cláusula de Transact-SQL)
CREATE PROCEDURE (Transact-SQL)
CREATE FUNCTION (Transact-SQL)
CREATE TRIGGER (Transact-SQL)
CREATE QUEUE (Transact-SQL)