CONCESSIONE ESEGUI a tutte le procedure memorizzate

147

Il comando seguente autorizza l'utente "MyUser" a eseguire TUTTE le procedure memorizzate nel database?

GRANT EXECUTE TO [MyDomain\MyUser]

— Chad
fonte

244

SQL Server 2008 e versioni successive:

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

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

Solo per un utente (non un ruolo):

USE [DBName]
GO
GRANT EXECUTE TO [user]

— Antony Scott
fonte

28

+1 +: concede persino autorizzazioni EXECUTE a future procedure memorizzate, ad esempio quelle che non sono ancora nel tuo database - ma verranno create in seguito.

— marc_s,

2

Penso che valga la pena notare che userpotresti dover essere racchiuso tra parentesi quadre. Questo era vero nel mio caso d'uso almeno in parte perché il mio utente aveva un dominio collegato (cioè aveva un carattere \ in esso). modifica: risolto carattere barra senza

— escape

1

Perché non assegnare l'utente al ruolo db_ddladmin? "I membri del ruolo predefinito del database db_ddladmin possono eseguire qualsiasi comando DDL (Data Definition Language) in un database." - vedi qui

— Michael Tobisch

1

@MichaelTobisch qui deve solo eseguire Stored Procedures. Il ruolo DDL deve essere utilizzato negli scenari Crea, Modifica, Rilascia, ... Questi collegamenti devono essere utili: docs.microsoft.com/en-us/sql/relational-d database

— security

2

E il prossimo livello di aggiunta di un utente a un ruolo nel caso in cui salvi qualcuno un altro passo di ricerca. ALTER ROLE db_executor AGGIUNGI MEMBRO YourUserNameHere

— Piwaf

72

SQL Server 2005 ha introdotto la possibilità di concedere autorizzazioni di esecuzione del database a un principio del database, come descritto:

GRANT EXECUTE TO [MyDomain\MyUser]

Ciò garantirà l'autorizzazione nell'ambito del database, che include implicitamente tutte le procedure memorizzate in tutti gli schemi. Ciò significa che non è necessario concedere esplicitamente le autorizzazioni per procedura memorizzata.

Puoi anche limitare concedendo autorizzazioni di esecuzione dello schema se vuoi essere più granulare:

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

— Robin Minto
fonte

5

Fantastico poterlo fare su uno schema specifico, evitando quindi permessi su sys

— NotaLima

17

Oltre alle risposte sopra, vorrei aggiungere:

È possibile che si desideri concedere questo a un ruolo e quindi assegnare il ruolo all'utente. Supponiamo di aver creato un ruolo myAppRightstramite

CREATE ROLE [myAppRights]

allora puoi dare i diritti di esecuzione tramite

GRANT EXECUTE TO [myAppRights]

a quel ruolo.

Oppure, se vuoi farlo a livello di schema:

GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]

funziona anche (in questo esempio, il ruolo myAppRightsavrà diritti di esecuzione su tutti gli elementi dello schema in dboseguito).

In questo modo, devi farlo una sola volta e puoi assegnare / revocare facilmente tutti i diritti relativi alle applicazioni a / da un utente se devi modificarli in seguito - particolarmente utile se vuoi creare profili di accesso più complessi.

Nota: se concedi un ruolo a uno schema, ciò influisce anche sugli elementi che avrai creato in seguito - questo potrebbe essere utile o no a seconda del design che intendi, quindi tienilo a mente.

— opaco
fonte

-5

CONCESSIONE ESEGUITA A [RUOLO]

Questo sicuramente aiuta

— Sharon AS
fonte

Non si desidera concedere l'esecuzione al ruolo pubblico, si aprono problemi di sicurezza. Concedilo all'utente o al ruolo. Concedere l'esecuzione a specifici proc è il modo migliore per andare in modo da poter controllare chi sta colpendo cosa.

— ammills01,

Il sarcasmo qui non è appropriato per un sito di domande e risposte, specialmente quando produce risultati potenzialmente pericolosi.

— Christopher Brown,

"Ogni accesso appartiene al ruolo del server fisso pubblico e ogni utente del database appartiene al ruolo del database pubblico. Quando un accesso o un utente non sono stati concessi o negati permessi specifici su un sicuro, l'accesso o l'utente eredita i permessi concessi al pubblico su that secureable "Pertanto, concedere qualsiasi autorizzazione a PUBLIC significa concedere tali autorizzazioni a tutti gli utenti. Questa è una grande vulnerabilità. Leggi questo link per ulteriori informazioni: docs.microsoft.com/en-us/sql/relational-d database

— security

Con risposte come questa, non c'è da meravigliarsi che ci siano così tanti siti Web e database scarsamente sicuri là fuori. Accidenti amico.

— Dave Lucre,