OTORGAR EJECUTAR a todos los procedimientos almacenados

147

¿El siguiente comando efectivamente le da al usuario, "MyUser", permiso para ejecutar TODOS los procedimientos almacenados en la base de datos?

GRANT EXECUTE TO [MyDomain\MyUser]

— Chad
fuente

244

SQL Server 2008 y superior:

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor

Solo para un usuario (no un rol):

USE [DBName]
GO
GRANT EXECUTE TO [user]

— Antony Scott
fuente

28

+1 plus: incluso otorga permisos EXECUTE a futuros procedimientos almacenados, por ejemplo, aquellos que aún no están en su base de datos, pero se crearán más adelante.

— marc_s

2

Creo que vale la pena señalar que es userposible que tenga que estar entre corchetes. Esto fue cierto en mi caso de uso, al menos en parte porque mi usuario tenía un dominio adjunto (es decir, tenía un carácter \). editar: carácter de barra fija sin escape

— PrinceTyke

1

¿Por qué no asignar al usuario al rol db_ddladmin? "Los miembros de la función fija de base de datos db_ddladmin pueden ejecutar cualquier comando del lenguaje de definición de datos (DDL) en una base de datos". - mira aquí

— Michael Tobisch

1

@MichaelTobisch aquí solo necesita ejecutar procedimientos almacenados. El rol DDL debe usarse en los escenarios Crear, Modificar, Soltar, ... Estos enlaces deben ser útiles: docs.microsoft.com/en-us/sql/relational-databases/security/… y geeksforgeeks.org/sql-ddl-dml-dcl-tcl-commands

— QMaster

2

Y el siguiente nivel de agregar un usuario a un rol en caso de que ahorre a alguien otro paso de investigación. ALTERAR PAPEL db_executor AGREGAR MIEMBRO YourUserNameHere

— Piwaf

72

SQL Server 2005 introdujo la capacidad de otorgar permisos de ejecución de base de datos a un principio de base de datos, como ha descrito:

GRANT EXECUTE TO [MyDomain\MyUser]

Eso otorgará permiso en el alcance de la base de datos, que implícitamente incluye todos los procedimientos almacenados en todos los esquemas. Esto significa que no tiene que otorgar permisos explícitamente por procedimiento almacenado.

También puede restringir otorgando permisos de ejecución de esquema si desea ser más granular:

GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]

— Robin Minto
fuente

55

Genial poder hacer esto con un esquema específico, por lo que evita los permisos en el sistema

— RemarkLima

17

Además de las respuestas anteriores, me gustaría agregar:

Es posible que desee otorgar esto a un rol y luego asignar el rol a los usuarios. Supongamos que ha creado un rol a myAppRightstravés de

CREATE ROLE [myAppRights]

entonces puede otorgar derechos de ejecución a través de

GRANT EXECUTE TO [myAppRights]

a ese papel

O, si quieres hacerlo a nivel de esquema:

GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]

también funciona (en este ejemplo, el rol myAppRightstendrá derechos de ejecución en todos los elementos del esquema dbodespués).

De esta manera, solo tiene que hacerlo una vez y puede asignar / revocar todos los derechos de aplicación relacionados fácilmente a / desde un usuario si necesita cambiar eso más adelante, especialmente útil si desea crear perfiles de acceso más complejos.

Nota: Si concede un rol a un esquema, eso afecta también a los elementos que habrá creado más adelante; esto podría ser beneficioso o no dependiendo del diseño que pretendía, así que tenga esto en cuenta.

— Mate
fuente

-5

OTORGAR EJECUTAR A [PAPEL]

Este seguramente ayuda

— Sharon AS
fuente

No desea otorgar la ejecución al rol público, esto genera problemas de seguridad. Solo concédelo al usuario o rol. Conceder ejecutar a procesos específicos es la mejor manera de hacerlo para que pueda controlar quién está golpeando qué.

— ammills01

El sarcasmo aquí no es apropiado para un sitio de preguntas y respuestas, especialmente cuando produce resultados posiblemente peligrosos.

— Christopher Brown

"Cada inicio de sesión pertenece a la función fija de servidor público, y cada usuario de la base de datos pertenece a la función de base de datos pública. Cuando un inicio de sesión o usuario no ha recibido o se le han negado permisos específicos en un asegurable, el inicio de sesión o usuario hereda los permisos otorgados al público en eso asegurable "Otorgando permisos a PUBLIC, lo que significa otorgar esos permisos a todos los usuarios. Esta es una gran vulnerabilidad. Lea este enlace para obtener más información: docs.microsoft.com/en-us/sql/relational-databases/security/…

— QMaster

Con respuestas como esta, no es de extrañar que haya tantos sitios web y bases de datos mal protegidos por ahí. Caray hombre.

— Dave Lucre