Tilldela och ta bort rättigheter. Ställa in behörigheter grant-kommando Använder vyer för att filtrera privilegier

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] PÅ (tbl_name | * | *.* | db_name.*) TO user_name "lösenord"] [, användarnamn ...] ] ] ] ] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] PÅ (tbl_name | * | *.* | db_name.*) FROM user_name [, användarnamn ...]

GRANT ingår i MySQL version 3.22.11 och senare. I tidigare versioner av MySQL gör GRANT-satsen ingenting.

Med kommandona GRANT och REVOKE kan systemadministratörer skapa MySQL-användare och bevilja eller återkalla rättigheter till användare på fyra nivåer av privilegier:

Global nivå Globala privilegier gäller för alla databaser på den angivna servern. Dessa privilegier lagras i tabellen mysql.user. Databasnivå Databasbehörigheter gäller alla tabeller i den angivna databasen. Dessa privilegier lagras i tabellerna mysql.db och mysql.host. Bordsnivå Tabellbehörigheter gäller alla kolumner i den angivna tabellen. Dessa privilegier lagras i tabellen mysql.tables_priv. Kolumnnivå Kolumnbehörigheter gäller för enskilda kolumner i den angivna tabellen. Dessa privilegier lagras i tabellen mysql.columns_priv.

Om privilegier ges till en användare som inte finns skapas den användaren. För exempel på GRANT-kommandot, se avsnitt 4.3.5 Lägga till nya användare till MySQL.

Tabellen visar en lista över möjliga värden för parametern priv_type för GRANT- och REVOKE-satserna:

ALLT	Ställer in alla enkla privilegier utom MED GRANTALTERNATIV
ÄNDRA	Tillåter användning av ALTER TABLE
SKAPA	Tillåter användning av CREATE TABLE
SKAPA TILLÄMPLIGA BORD	Tillåter användning av CREATE TEMPORARY TABLE
RADERA	Tillåter användning av DELETE
SLÄPPA	Tillåter användning av DROP TABLE.
KÖR	Tillåter användaren att köra lagrade procedurer (för MySQL 5.0)
FIL	Tillåter användning av SELECT ... INTO OUTFILE och LOAD DATA INFILE .
INDEX	Tillåter användning av CREATE INDEX och TAPP INDEX
FÖRA IN	Tillåter användning av INSERT
LÅS BORD	Tillåter användning av LOCK TABLES på tabeller som har SELECT-privilegiet.
BEARBETA	Tillåter användning av VISA HELA PROCESSLISTA
REFERENSER	Reserverad för framtida bruk
LADDA OM	Tillåter användning av FLUSH
REPLIKATIONSKLIENT	Ger användaren rätt att fråga platsen för master- och slavservrarna.
REPLIKATIONSSLAV	Nödvändigt för slavservrar under replikering (för att läsa information från huvudserverns binära loggar).
VÄLJ	Tillåter användning av SELECT
VISA DATABASER	VISA DATABASER Listar alla databaser.
STÄNGA AV	Tillåter användning av mysqladmin avstängning
SUPER	Låter dig upprätta en anslutning (en gång), även om max_connections nås, och kör kommandon CHANGE MASTER , KILL thread , mysqladmin debug , PURGE MASTER LOGS och SET GLOBAL
UPPDATERING	Tillåter användning av UPDATE
ANVÄNDANDE	Synonym för ``utan privilegier''.

USAGE-värdet kan anges om du behöver skapa en användare utan privilegier.

Behörigheterna SKAPA TILLÄMPLIGA TABELLER, UTFÖR, LÅS TABELL, REPLIKATION ..., VISA DATABASER och SUPER är nya i version 4.0.2. För att dra nytta av dessa nya privilegier efter uppgradering till version 4.0.2 måste du köra mysql_fix_privilege_tables-skriptet.

I äldre versioner av MySQL ger PROCESS-privilegiet samma rättigheter som det nya SUPER-privilegiet.

För att återkalla en användares privilegier som beviljats ​​av kommandot GRANT, använd värdet priv_type i GRANT OPTION:

Mysql> ÅTERVÄNDA BIDRAG ALTERNATIV PÅ ... FRÅN ...;

De enda priv_type-värdena som kan anges för en tabell är: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, IDEX och ALTER.

De enda priv_type-värdena som kan specificeras för en kolumn (när man använder column_list-operatorn) är SELECT , INSERT och UPDATE .

Globala privilegier kan ställas in med ON *.*-syntaxen, och databasbehörigheter kan ställas in med ON db_name.*-syntaxen. Om du anger PÅ * medan den aktuella databasen är öppen, kommer privilegier att ställas in för den databasen. ( Varning: om du anger PÅ * när frånvaro den aktuella databasen är öppen, detta kommer att påverka globala privilegier!)

För att kunna definiera rättigheter för användare på specifika datorer ger MySQL möjligheten att ange användarnamnet (användarnamn) i formuläret. Om du behöver ange en användarsträng som innehåller specialtecken (som "-") eller en värdsträng som innehåller specialtecken eller jokertecken (som "%"), kan du bifoga namnet fjärrdator eller användare inom citattecken (till exempel "test-användare"@"test-värdnamn").

Du kan också inkludera jokertecken i fjärrdatorns namn. Till exempel, "%.loc.gov" hänvisar till användaren av alla fjärrdatorer i loc.gov-domänen, och "144.155.166.%" hänvisar till användaren av alla fjärrdatorer i klass C-undernätet 144.155.166.

Den enkla formanvändaren är en synonym för "%" .

MySQL stöder inte jokertecken i användarnamn. Anonyma användare definieras genom att infoga User=""-poster i tabellen mysql.user eller genom att skapa en användare med ett tomt namn med kommandot GRANT.

Notera: Om anonyma användare tillåts ansluta till MySQL-servern måste du också ge privilegier till alla lokala användare som , eftersom annars, när en användare försöker logga in på MySQL från den lokala datorn, kommer tabellen mysql.user att använda den anonyma användaren logga in!

För att kontrollera om detta händer på din dator, kör följande fråga:

Mysql> SELECT Host, User FROM mysql.user WHERE User="";

För närvarande stöder GRANT-kommandot namn på fjärrdatorer, tabeller, databaser och kolumner med upp till 60 tecken. Användarnamnet får inte innehålla mer än 16 tecken.

Behörigheter för en tabell eller kolumn skapas med den logiska ELLER-operatorn från privilegierna på var och en av de fyra nivåerna. Till exempel, om tabellen mysql.user indikerar att användaren har den globala SELECT-behörigheten, återkallas inte den behörigheten på databas-, tabell- eller kolumnnivå.

Behörigheterna för en kolumn kan beräknas enligt följande:

Globala privilegier ELLER (databasbehörigheter OCH fjärrdatorbehörigheter) ELLER tabellprivilegier ELLER kolumnprivilegier

I de flesta fall definieras användarrättigheter på endast en behörighetsnivå, så denna procedur är vanligtvis inte så komplex som beskrivits ovan. detaljerad informationÅtgärdssekvensen för att kontrollera privilegier presenteras i avsnitt 4.2 Allmänna säkerhetsfrågor och MySQL-åtkomstbehörighetssystemet.

Om privilegier ges till en användare/fjärrkombination som inte finns i mysql.user-tabellen, läggs en post till i mysql.user-tabellen och förblir i tabellen tills den tas bort med kommandot DELETE. Med andra ord kan GRANT-kommandot skapa användarposter i tabellen, men kommandot REVOKE kan inte ta bort dem. Detta måste göras med kommandot DELETE.

Om du har databasrättigheter skapas en post i tabellen mysql.db om det behövs. Den här posten raderas efter att alla privilegier för denna databas har tagits bort med kommandot REVOKE.

Om en användare inte har några privilegier på en tabell, visas inte tabellen när användaren begär en lista med tabeller (till exempel genom att använda SHOW TABLES-satsen).

WITH GRANT OPTION-satsen ger en användare möjligheten att ge andra användare alla privilegier som han själv har på en specificerad behörighetsnivå. Försiktighet måste iakttas när du beviljar GRANT-privilegiet, eftersom två användare med olika privilegier kan kombinera sina privilegier!

Alternativen MAX_QUERIES_PER_HOUR # , MAX_UPDATES_PER_HOUR # och MAX_CONNECTIONS_PER_HOUR # är nya i MySQL version 4.0.2. Dessa inställningar begränsar antalet förfrågningar, uppdateringar och inloggningar som en användare kan göra på en timme. Om satt till 0 (standard), betyder detta att det inte finns några begränsningar för denna användare. Se avsnitt.

Du kan inte ge en annan användare ett privilegium som du inte har. GRANT-privilegiet tillåter dig att bara bevilja de privilegier som du har.

Observera att om en användare tilldelas GRANT-behörigheten på en viss privilegienivå, så kan alla privilegier som den användaren redan har (eller kommer att tilldelas i framtiden!) på den nivån också tilldelas den användaren. Låt oss anta att en användare har fått INSERT-behörighet på en databas. Om du sedan beviljar SELECT-privilegiet i databasen och anger WITH GRANT OPTION, kan användaren bevilja inte bara SELECT-behörigheten, utan även INSERT-behörigheten. Om du sedan ger användaren UPDATE-privilegiet i databasen, kan användaren sedan utfärda INSERT, SELECT och UPDATE.

ALTER-privilegier bör inte tilldelas vanliga användare. Detta ger användaren möjlighet att bryta privilegiesystemet genom att byta namn på tabeller!

Observera att om tabell- eller kolumnprivilegier används för ens en användare, kontrollerar servern tabell- och kolumnprivilegierna för alla användare och detta saktar ner MySQL något.

När mysqld startar läses alla privilegier in i minnet. Databas-, tabell- och kolumnprivilegier träder i kraft omedelbart, medan privilegier på användarnivå träder i kraft nästa gång användaren ansluter. Ändringar av som görs med kommandona GRANT och REVOKE bearbetas omedelbart av servern. Om du ändrar privilegietilldelningstabeller manuellt (med INSERT , UPDATE , etc.), måste du köra FLUSH PRIVILEGES eller mysqladmin flush-privilege s-satsen för att instruera servern att ladda om. Se avsnitt 4.3.3 När behörighetsändringar träder i kraft.

De viktigaste skillnaderna mellan ANSI SQL- och MySQL-versionerna av GRANT-kommandot är följande:

• I MySQL tilldelas privilegier till kombinationen av användarnamn + fjärrdator, inte bara användarnamnet.
• ANSI SQL har inte globala eller databasnivåprivilegier, och ANSI SQL stöder inte alla MySQL-privilegier. MySQL, å andra sidan, stöder inte ANSI SQL TRIGGER, EXECUTE eller UNDER-privilegierna.
• ANSI SQL-behörighetsstrukturen är hierarkisk. Om du tar bort en användare återkallas alla rättigheter som tilldelats den användaren. I MySQL återkallas inte tilldelade privilegier automatiskt, du måste ta bort dem själv om det behövs.
• I MySQL kan en användare INFOGA en tabell om de har INSERT-behörighet på endast ett fåtal kolumner i den tabellen. Kolumner som inte har INSERT-behörigheten kommer att ställas in på sina standardvärden. ANSI SQL kräver INSERT-behörighet i alla kolumner.
• När du släpper en tabell i ANSI SQL kommer alla privilegier för den tabellen att återkallas. Om du återkallar en behörighet i ANSI SQL, återkallas också alla behörigheter som tilldelades baserat på den behörigheten. I MySQL kan privilegier endast tas bort med kommandot REVOKE eller genom att ändra MySQL-behörighetstilldelningstabellerna.

För en beskrivning av användningen av REQUIRE, se avsnitt 4.3.9 Använda säkra anslutningar.

Användarkommentarer

Postat av Frank Wortner

[Radera] [Redigera]

Jag hade inga problem med ld. DEC (Compaq) kanske
har fixat ld i ett patchkit. Du kanske vill
installera den senaste patchsatsen för din Digital Unix
(Tru64 Unix) innan du bygger MySQL. Patch kit
finns på
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Postat av lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

För källinstallationer hänvisar dessa instruktioner till katalogstrukturen förutsatt att "usr/local" användes (standard) med configure. Men instruktionerna på föregående sida (för kompilering/installation) föreslår att du använder:

./configure --prefix=/usr/local/mysql

För att vara konsekvent (och detta orsakar mig en del krångel med Perl, så det är inte rent semantiskt), bör instruktionerna på den här sidan anta att /usr/local/mysql angavs som installationskatalogen med configure.

Postat av Linda Wright lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

Detta är förmodligen det viktigaste och minsta
uppskattade avsnitt av hela mySQL
dokumentation för förstagångsanvändare av mySQL. IMHO,
läser denna sida i samband med
http://www.mysql.com/doc/P/r/Privileges.html är en
måste för att planera alla säkra databassystem
av någon verklig sofistikering.

Upplagt av Christopher Raymond lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

Jag försöker installera MySQL under OS X Public Beta. När jag kör skriptet mysql_install_db får jag ett felmeddelande:

Dyld: ./bin/mysqld kan inte öppna biblioteket: /usr/lib/libpthread.A.dylib (Ingen sådan fil eller katalog, errno = 2)
Installation av bidragstabeller misslyckades!

Jag antar att skriptet letar efter en katalog som inte existerar eftersom Apple har en lite annorlunda katalognamnstruktur. Kanske måste detta skript modifieras för OS X-distributionen.

Kan någon hjälpa?

Postat av Mark Zieg lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

Det skulle vara trevligt om det fanns ett alternativ att logga anslutningar, men inte frågor.

Postat av Bennett Haselton lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

Om du är inloggad som mysql root-användare, utan en aktuell databas vald, och du försöker
ge alla privilegier till en användare med kommandot:

GE ALLA PRIVILEGIER PÅ * TILL bhaselto

Då kommer inte RELOAD, SHUTDOWN, PROCESS, FILE och GRANT att beviljas, vilket kan vara
verifieras genom att kontrollera "user"-tabellen i "mysql"-databasen. (Detta är förmodligen genom design,
eftersom dessa privilegier kan göra en användare "för kraftfull".)

Upplagt av DC Hill lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

OBS: Om du har beviljat privilegier till en användare på en viss databas, eller på någon lägre nivå än så, anropar du "REVOKE ALL ON *.* FROM ;" kommer INTE att återkalla privilegier på dessa nivåer. *.* i ovanstående uttalande betyder "global", inte "alla (individuella) tabeller på alla (individuella) databaser. Det uttalandet kommer ENDAST att återkalla globala privilegier, som lagras i mysql.user-tabellen. Du MÅSTE återkalla några mer specifika privilegier på samma sätt som de beviljades, om du vill att de ska tas bort från privilegietabellerna. (dvs. - GRANTA ALLA ON foo.* TO ; => REVOKE ALL ON foo.* FROM ;) Jag hoppas att detta sparar några av du lite tid och frustration.

Upplagt av Cris Perdue lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

"Om du har processprivilegiet kan du se
alla trådar.
Annars kan du bara se dina egna trådar."

Postat av FreeBSD Forums lördagen den 16 februari 2002, kl 22:21

[Radera] [Redigera]

Du kan använda phpMyAdmin webbaserat verktyg för att göra mycket
av mySQL-administratörsfunktioner. href="http://www.freebsdforums.org"
>FreeBSD-forum

Upplagt av måndagen den 25 februari 2002, kl. 06:03

[Radera] [Redigera]

Verifierad på MySQL 3.23.36 på Red Hat Linux 7.1:
Observera att om du skriver
använd a_c;
bevilja välj på * till ;
du kommer att ges tillgång till någon
databas som matchar "a_c" där understrecket är en
jokertecken. (Sällan ett problem, antar jag).
Rätta till med
uppdatera mysql.db set db="a\_c" där db="a_c";

Upplagt av jan behrens tisdagen den 9 juli 2002, @01:31

[Radera] [Redigera]

ovannämnda bugg från DAN ELIN i x.x.41 är
uppenbarligen fortfarande giltig i x.x.51, jag kan inte logga in på en
databas efter att ha beviljat privilegier och fått en
lösenord till en ny användare (ja, jag spolade
privilegier).............endast root-åtkomst är möjlig

Upplagt av Dan Egli torsdagen den 4 april 2002, kl 20:33

[Radera] [Redigera]

Det verkar finnas en bugg i 3.23.41 som använder Grant.
Endast root kan komma åt mysql-databasen, till och med
efter att ha använt Grant för att bevilja privs på vad som helst
databas/tabell/kolumn/ect.. får du alltid
tillstånd nekad, oavsett.

Postat av Lars Aronsson lördagen den 8 juni 2002, kl 11:16

["%". När jag försöker ta bort dem får jag höra en viss databas, men inga globala privilegier SKAPA TILLÄMPLIGT TABELL-behörighet på den databasen är nekad. Du måste ge global CREATE __and__ global SKAPA TILLFÄLLIGA TABELLER för användaren. IOW: BETYD SKAPA, SKAPA TILLFÄLLIGA BORD PÅ *.* TILL ; Det behöver inte sägas att detta påverkar säkerheten tacksamt. Upplagt av söndagen den 25 augusti 2002, kl. 09:17 [Radera] [Redigera] Tillfälliga filer är en bra idé men även med Skapa och skapa tillfälliga filrättigheter i användarfil (globala rättigheter) fungerar det fortfarande inte. Detta verkar vara dåligt utformat. Upplagt av Brad Bulger måndagen den 2 september 2002, klockan 04:09 [Radera] [Redigera] Det bör noteras att endast MED BIDRAG tillåter användaren att ge privilegier till användare som redan finns. Den automagiska skapandet av användare uppgifter gör inte tillämpa - du får ett felmeddelande som användaren med privilegiet GRANT OPTION gör har inte tillgång till "mysql"-databasen. Detta är förmodligen en bra sak, men det måste dokumenteras. Upplagt av Michael Babcock fredagen den 8 november 2002, klockan 13:00 [Radera] [Redigera] VISA MASTER STATUS kräver PROCESS-behörighet. Andra sådana udda kombinationer bör dokumenteras. Upplagt av Dee Kintaudi torsdagen den 21 november 2002, klockan 12:42 [Radera] [Redigera] Okej, jag har en fråga och ett problem med Mysql och lösenord:). Jag försökte använda flera av alternativen och de flesta av dem har inte fungerat. Dock en lösningen fungerade och jag testade den två gånger och den var solid. Självklart tappade jag den lilla papperslappen jag skrev ut det och jag kan inte hitta det här lösning var som helst, som om den inte fanns eller kanske jag föreställde sig det. Lösningen som fungerade för mig, innan jag tappade bort den lilla papperslappen skrev jag ner den på går något sånt här..... Sätt in i användarrot Lösenord "mitt lösenord" och så något med "Y", "Y", "Y", (ungefär ett dussin eller 15 gånger eller så) Men jag kan inte hitta den här lösningen någonstans någon som hjälper mig här? Jag tycker att det skulle vara så trevligt om de bara lade det här genom hela sin dokumentation istället för att försöka Göm det. Jag tror att detta skulle lösa många problem. Bara sätta lösenord = "Y", "Y", "Y", det är som att de skäms för det eller något. Upplagt av AJIT DIXIT måndagen den 25 november 2002, kl 06:56 [Radera] [Redigera] När jag arbetar med multi-table uppdatering med root-användare det fungerar bra När jag arbetar med icke-rootanvändare får jag ett felmeddelande SQL: uppdatera återförsäljare, områden set a_nm = aname där acd = area

I det här kapitlet kommer du att lära dig hur du arbetar med privilegier. Som diskuterats i kapitel 2 används SQL vanligtvis i miljöer som kräver användarigenkänning och åtskillnad mellan olika användare av system. I allmänhet skapar databasadministratörer själva användare och ger dem privilegier. Å andra sidan har användare som själva skapar tabeller rättigheter att hantera dessa tabeller. Privilegier är det som avgör om en angiven användare kan utföra ett givet kommando. Det finns flera typer av privilegier som motsvarar flera typer av operationer. Behörigheter beviljas och återkallas med två SQL-kommandon: - GRANT och REVOKE. Det här kapitlet kommer att visa dig hur dessa kommandon används.

ANVÄNDARE

Varje användare i en SQL-miljö har ett speciellt identifieringsnamn eller -nummer. Terminologin är olika överallt, men vi har valt (efter ANSI) att referera till den eller numret som Access Identifier (ID). Ett kommando som skickas till databasen är associerat med en specifik användare; eller på annat sätt, en speciell åtkomstidentifierare. Eftersom det hänför sig till en SQL-databas är behörighets-ID:t användarnamnet, och SQL kan använda det speciella nyckelordet USER, som hänvisar till det åtkomst-ID som är kopplat till det aktuella kommandot. Kommandot tolkas och tillåts (eller nekas) baserat på information associerad med åtkomst-ID för användaren som utfärdar kommandot.

REGISTRERING

I system med många användare finns det någon form av inloggningsprocedur som användaren måste genomföra för att få tillgång till datorsystemet. Denna procedur bestämmer vilket åtkomst-ID som kommer att kopplas till den aktuella användaren. Vanligtvis måste varje person som använder databasen ha sitt eget åtkomst-ID och blir vid registrering en giltig användare. Men ofta kan användare med många uppgifter registreras under olika åtkomst-ID, eller omvänt kan ett åtkomst-ID användas av flera användare. Ur ett SQL-perspektiv är det ingen skillnad mellan dessa två fall; det behandlar användaren helt enkelt som deras åtkomst-ID. SQL-databasen kan använda sin egen inloggningsprocedur, eller så kan den tillåta ett annat program, t.ex operativ system(huvudprogrammet som körs på din dator), bearbeta registreringsfilen och skaffa åtkomst-ID från detta program. På ett eller annat sätt kommer SQL att ha ett åtkomst-ID att associera med dina handlingar, och nyckelordet USER kommer att vara relevant för dig.

TILLHANDAHÅLLANDE PRIVILEGIER

Varje användare i en SQL-databas har en uppsättning privilegier. Detta är vad användaren får göra (kanske är det en loggfil, som kan betraktas som en minimibehörighet). Dessa privilegier kan ändras med tiden - nya läggs till, gamla tas bort. Vissa av dessa privilegier är definierade i ANSI SQL, men det finns ytterligare privilegier som också krävs. SQL-privilegier som definieras av ANSI är inte tillräckliga i de flesta verkliga situationer. Å andra sidan kan de typer av privilegier som behövs variera med vilken typ av system du använder - för vilket ANSI inte ger några rekommendationer. Behörigheter som inte är en del av SQL-standarden kan använda syntax som liknar och inte helt överensstämmer med standarden.

STANDARDPRIVILEGIER

SQL-behörigheter som definieras av ANSI är objektbehörigheter. Detta innebär att användaren har privilegiet att utföra ett givet kommando endast på ett specifikt objekt i databasen. Naturligtvis måste privilegier skilja mellan dessa objekt, men ett privilegiesystem baserat enbart på ett objekts privilegier kan inte hantera allt som SQL behöver, som vi kommer att se längre fram i detta kapitel. Ett objekts privilegier är associerade med både användare och tabeller. Det vill säga, privilegiet ges till en specifik användare i en specificerad tabell, eller underliggande tabell eller vy. Du måste komma ihåg att användaren som skapade tabellen (av vilket slag som helst) är ägaren till denna tabell.

Detta innebär att användaren har alla privilegier i denna tabell och kan överföra privilegier till andra användare i denna tabell. Behörigheter som kan tilldelas en användare:

VÄLJ En användare med denna behörighet kan köra frågor på tabellen.

INSERT En användare med denna behörighet kan utfärda ett INSERT-kommando på en tabell.

UPDATE En användare med denna behörighet kan utfärda ett UPDATE-kommando på en tabell. Du kan begränsa denna behörighet till specifika tabellkolumner.

DELETE En användare med denna behörighet kan utfärda ett DELETE-kommando på en tabell.

REFERENSER En användare med denna behörighet kan definiera en främmande nyckel som använder en eller flera kolumner i denna tabell som en överordnad nyckel. Du kan begränsa denna behörighet till vissa kolumner. (Se kapitel 19 för detaljer om främmande nyckel och överordnad nyckel.)

Dessutom kommer du att stöta på icke-standardiserade objektprivilegier, såsom INDEX, som ger rätt att skapa ett index på en tabell, SYNONYM, som ger rätt att skapa en synonym för ett objekt, vilket kommer att förklaras i kapitel 23, och ALTER, som ger rätten att utföra kommandot ALTER TABLE på en tabell. SQL-motorn tilldelar dessa privilegier till användare som använder kommandot GRANT.

GRANT TEAM

Låt oss anta att användaren Diane har en kundtabell och vill tillåta användaren Adrian att fråga den. Diane ska sedan ange följande kommando:

BIDRAG INSERT PÅ Säljare TILL Diane;

Nu kan Adrian köra frågor mot tabellen Kunder. Utan andra privilegier kan han bara välja värden; men kan inte utföra någon åtgärd som skulle påverka värdena i tabellen Kunder (inklusive att använda tabellen Kunder som den överordnade tabellen för den främmande nyckeln, vilket begränsar de ändringar som kan göras av värdet i tabellen Kunder).

När SQL tar emot ett GRANT-kommando kontrollerar den privilegierna för användaren som utfärdar kommandot för att avgöra om GRANT-kommandot är giltigt. Adrian kan inte ge detta kommando på egen hand. Den kan inte heller ge SELECT-behörighet till en annan användare: tabellen tillhör fortfarande Diane (vi ska visa senare hur Diane kan ge Adrian SELECT-behörighet till andra användare).

Syntaxen är densamma som för att bevilja andra privilegier. Om Adrian är ägaren till Sellers-tabellen kan han tillåta Diane att skriva in rader i den med hjälp av följande klausul

BIDRAG INSERT PÅ Säljare TILL Diane; Diane har nu rätt att placera en ny säljare i tabellen.

PRIVILEGIER GRUPPER, ANVÄNDARGRUPPER

Du bör inte begränsa dig till att ge en enskild behörighet till en enskild användare med kommandot GRANT. Kommaseparerade listor över privilegier eller användare är helt acceptabla. Stephen kan tillhandahålla både SELECT och INSERT i ordertabellen för Adrian

BIDRAG SELECT, INSERT PÅ beställningar TILL Adrian; eller för både Adrian och Diane GRANNT SELECT, INSERT PÅ beställningar TILL Adrian, Diane;

När privilegier och användare listas på detta sätt, tilldelas hela listan med privilegier till alla angivna användare. I strikt ANSI-tolkning kan du inte ge privilegier på många tabeller samtidigt med ett enda kommando, men vissa implementeringar kan mildra denna begränsning genom att tillåta dig att specificera flera tabeller, separerade med kommatecken, så att hela listan med privilegier kan beviljas för alla angivna tabeller. .

BEGRÄNSNING AV PRIVILEGIER PÅ SPECIFIKA KOLUMNER

Alla objektbehörigheter använder samma syntax, förutom kommandona UPDATE och REGERNCES, som inte kräver kolumnnamn. UPPDATERING-privilegiet kan beviljas som andra privilegier:

BIDRAG UPPDATERING PÅ Säljare TILL Diane;

Detta kommando gör det möjligt för Diane att ändra värdena i någon eller alla kolumner i leverantörstabellen. Men om Adrian vill hindra Diane från att ändra till exempel provisioner kan han komma in

BILDA UPPDATERING (komm.) PÅ Säljare TILL Diane;

Med andra ord måste den helt enkelt ange den specifika kolumn som UPDATE-behörigheten ska tillämpas på, inom parentes efter tabellnamnet. Namnen på flera tabellkolumner kan anges i valfri ordning, separerade med kommatecken:

BILDA UPPDATERING (stad, kommun) PÅ Säljare TILL Diane;

REFERENSER följer samma regel. När du beviljar REFERENCES-behörigheten till en annan användare, kommer de att kunna skapa främmande nycklar som refererar till kolumner i din tabell som överordnade nycklar. Precis som UPDATE kan REFERENCES-behörigheten anges som en lista över en eller flera kolumner för vilka privilegiet är begränsat. Till exempel kan Diane ge Stephen rätten att använda Kundtabellen som den överordnade nyckeltabellen med följande kommando:

GE REFERENSER (cname, cnum) PÅ kunder TILL Stephen; Detta kommando ger Stephen rätten att använda kolumnerna cnum och cname som överordnade nycklar till alla främmande nycklar i hans tabeller. Stephen kan kontrollera hur detta görs. Den kan definiera (cname, cnum) eller, i vårt fall, (cnum, cname), som en tvåkolumns föräldranyckel matchad av en främmande nyckel till två kolumner i en av sina egna tabeller. Eller så kan den skapa separata främmande nycklar för att referera till kön individuellt, och därigenom säkerställa att Diane har en föräldranyckel tilldelad (se kapitel 19).

Utan några begränsningar för främmande nyckelnummer måste den baseras på dessa föräldernycklar, och föräldernycklarna för olika främmande nycklar måste tillåtas överlappa varandra.

Precis som med UPDATE-privilegiet kan du utesluta en lista med kolumner och därmed tillåta att alla kolumner används som överordnade nycklar. Adrian kan ge Diane rätten att göra detta med följande kommando:

GE REFERENSER OM Säljare TILL Diane;

Naturligtvis kommer privilegiet endast att kunna användas på kolumner som har de begränsningar som krävs av överordnade nycklar.

ANVÄNDER ALLA OCH OFFENTLIGA ARGUMENT

SQL stöder två argument för GRANT-kommandot som har en speciell betydelse: ALL PRIVILEGES, eller helt enkelt ALL och PUBLIC. ALL används istället för privilegienamn i GRANT-kommandot för att ge alla privilegier i en tabell. Till exempel kan Diane ge Stephen hela uppsättningen av privilegier i tabellen Kunder med följande kommando:

GE REFERENSER OM Säljare TILL Diane;

(UPPDATERING och REFERENSER-privilegier gäller naturligtvis för alla kolumner.) Här är ett annat sätt att säga samma sak:

GE ALLT PÅ kunder TILL Stephen;

PUBLIC är mer som en catch-all-argumenttyp än en användarbehörighet. När du beviljar publiceringsbehörigheter får alla användare dem automatiskt. Oftast används detta för SELECT-privilegiet på vissa underliggande tabeller eller vyer som du vill göra tillgängliga för alla användare. För att tillåta alla användare att se beställningstabellen kan du till exempel ange följande:

BIDRAG VAL PÅ BESTÄLLNINGAR TILL ALLMÄNHETEN;

Naturligtvis kan du ge någon eller alla privilegier till samhället, men det är förmodligen inte tillrådligt. Alla privilegier utom SELECT tillåter användaren att ändra (eller, i fallet med REFERENCER, begränsa) innehållet i tabellen. Att tillåta alla användare att ändra innehållet i dina tabeller kommer att orsaka problem.

Även om du har ett litet företag och alla dina nuvarande användare är kapabla att utföra modifieringskommandon på en given tabell, skulle det vara bättre att ge privilegier till varje användare individuellt än att ge samma privilegier till alla. PUBLIC är inte begränsad till att överföra den till enbart nuvarande användare. Några Ny användare läggs till ditt system kommer automatiskt att få alla privilegier som tidigare tilldelats alla, så om du vill begränsa tabellåtkomst till alla, nu eller i framtiden, är det bäst att ge andra privilegier än SELECT till enskilda användare.

BEHANDLING AV PRIVILEGIER MED ATT ANVÄNDA MED BIDRAG

Ibland vill skaparen av ett bord att andra användare ska kunna få privilegier på hans bord. Detta görs vanligtvis i system där en eller flera personer skapar flera (eller alla) bastabellerna i en databas och sedan delegerar ansvaret för dem till de som faktiskt ska arbeta med dem. SQL låter dig göra detta med hjälp av WITH GRANT OPTION-satsen. Om Diane ville att Adrian skulle kunna ge SELECT-privilegiet på Customers-tabellen till andra användare, skulle hon ge honom SELECT-privilegiet med hjälp av WITH GRANT OPTION-klausulen:

BIDRAG VAL PÅ kunder TILL Adrian MED BIDRAGSMÖJLIGHET; Adrian förvärvade sedan rätten att överföra SELECT-privilegiet till tredje part; den kan utfärda kommandot GRANT SELECT ON Diane.Customers TO Stephen; eller till och med GE VAL PÅ Diane. Kunder TILL Stephen MED BIDRAGSMÖJLIGHET; En användare med ett BEHANDLA ALTERNATIV på ett visst privilegium på ett givet bord kan i sin tur bevilja det privilegiet på samma bord, med eller utan ett BEHANDLA ALTERNATIV, till vilken annan användare som helst. Detta ändrar inte ägandet av själva bordet; som tidigare tillhör bordet dess skapare. (Därför måste beviljade användare prefixet ägaråtkomst-ID när de hänvisar till dessa tabeller. Nästa kapitel kommer att visa dig denna metod.) En användare som använder GRANT ALTERNATIV på alla privilegier för en given tabell kommer att ha full auktoritet i den tabellen.

AVBRYTNING AV PRIVILEGIER

Precis som ANSI tillhandahåller kommandot CREATE TABLE för att skapa en tabell, snarare än kommandot DROP TABLE för att bli av med det, låter GRANT-kommandot dig ge privilegier till användare utan att tillhandahålla ett sätt att ta tillbaka dem. Behovet av att ta bort privilegier beror på REVOKE-kommandot, som faktiskt är ett standardverktyg med en ganska tydlig form av inmatning. Syntaxen för kommandot REVOKE liknar GRANT, men har motsatt betydelse. För att ta bort INSERT-privilegiet för Adrian i Order-tabellen kan du gå in

ÅTERVÄNDA INFOGA PÅ beställningar FRÅN Adrian;

Att använda listor med privilegier och användare är tillåtet här som med GRANT, så du kan ange följande kommando:

REVOKE INSERT, DELETE PÅ kunder FRÅN Adrian, Stephen; Det finns dock en viss oklarhet här. Vem har rätt att återkalla privilegier? När förlorar en användare med rätt att överföra privilegier till andra denna rätt? Kommer användarna som han gav dessa privilegier också att förlora dem? Eftersom detta inte är en standardfunktion finns det inga auktoritativa svar på dessa frågor, men det vanligaste tillvägagångssättet är detta: * Behörigheter återkallas av användaren som beviljat dem, och återkallelsen kommer att överlappa, det vill säga att den automatiskt sprids till alla användare som fått privilegiet från honom.

ANVÄNDA VISNINGAR FÖR ATT FILTRERA PRIVILEGIER

Du kan göra behörighetsåtgärder mer exakta genom att använda vyer. När du beviljar en behörighet på en bastabell till en användare, sprids den automatiskt till alla rader och, när du använder de möjliga undantagen UPDATE och REFERENCER, till alla kolumner i tabellen. Genom att skapa en vy som refererar till den underliggande tabellen och sedan överföra privilegiet till vyn istället för tabellen, kan du begränsa dessa privilegier till alla uttryck i frågan som finns i vyn. Detta förbättrar avsevärt de grundläggande funktionerna för GRANT-kommandot.

VEM KAN LÄMNA ANMÄLAN?

För att skapa en vy måste du ha SELECT-behörighet på alla tabeller som du refererar till i vyn. Om vyn är modifierbar kommer alla INSERT-, UPDATE- och DELETE-behörigheter du har på bastabellen att automatiskt överföras till vyn. Om du saknar ändringsprivilegier på bastabellerna kommer du inte att kunna ha dem på vyerna du skapar, även om dessa vyer i sig är modifierbara. Eftersom främmande nycklar inte används i vyer, används aldrig REFERENCES-privilegiet när vyer skapas. Alla dessa begränsningar definieras av ANSI. Icke-standardiserade systembehörigheter (diskuteras senare i det här kapitlet) kan också aktiveras. I de följande avsnitten kommer vi att anta att skaparna av vyerna vi diskuterar har privata eller lämpliga privilegier på alla underliggande tabeller.

BEGRÄNSNING AV VÄLJPRIVILEGE PÅ SPECIFIKA KOLUMNER

Låt oss säga att du vill ge användaren Claire möjligheten att bara se snum- och sname-kolumnerna i tabellen Försäljning. Du kan göra detta genom att ange namnen på dessa kolumner i vyn

SKAPA VY Clairesview AS SELECT snum, sname FRÅN Säljare; och ge Claire SELECT-privilegiet på visningen snarare än på själva Sellers-bordet: GANT SELECT På Clairesview till Claire; Du kan skapa privilegier specifikt för kolumner, som att använda andra privilegier, men för ett INSERT-kommando kommer detta att infoga standardvärden, och för ett DELETE-kommando har kolumnbegränsningen ingen effekt. REFERENSER och UPPDATERING privilegier kan naturligtvis göra kolumner specifika utan att tillgripa en vy.

BEGRÄNSNING AV PRIVILEGIER FÖR SPECIFIKA STRÄNGAR Vanligtvis är ett mer användbart sätt att filtrera privilegier med vyer att använda vyn för att få privilegiet att gälla endast för vissa rader. Detta gör du naturligt genom att använda ett predikat på vyn som avgör vilka rader som ingår. För att ge användaren Adrian UPPDATERA-privilegiet på Customers-tabellen för alla kunder i London, kan du skapa en vy så här:

SKAPA VY Londoncust SOM VÄLJ * FRÅN Kunder VAR stad = "London" MED KONTROLLVAL; Du måste sedan ge UPDATE-privilegiet på det här bordet till Adrian: GANTU UPPDATERING PÅ Londonkund TILL Adrian; Detta är skillnaden mellan privilegiet för vissa rader och UPDATE-privilegiet för vissa kolumner, vilket gäller alla kolumner i tabellen Kunder, men inte för rader, bland vilka rader med ett annat könsvärde för staden än London inte kommer att beaktas . WITH CHECK OPTION-klausulen hindrar Adrian från att ändra stadens könsvärde till något annat än London. GER ENDAST TILLGÅNG TILL EXTRAHERADE DATA En annan möjlighet är att erbjuda användarna tillgång till den data som redan har hämtats, snarare än de faktiska värdena i tabellen. Aggregatfunktioner kan vara mycket bekväma när du använder denna metod. Du kan skapa en vy som ger antalet, genomsnittet och totalen för beställningar för varje dag av beställningen: CREATE VIEW Datetotals AS SELECT odate, COUNT (*), SUM (amt), AVG (amt) FROM Orders GROUP BY odate; Du ger nu användaren Diane privilegiet SELECT i vyn Datumtotals: BETYD SELECT ON Datetotals TO Diane; ANVÄNDA REPRESENTATIONER SOM ETT ALTERNATIV TILL BEGRÄNSNINGAR En av de senaste tillämpningarna i serien, som beskrivs i kapitel 18, är användningen av vyer med MED KONTROLLOPTION som ett alternativ till begränsningar. Låt oss säga att du ville försäkra dig om att alla stadens könsvärden i tabellen Leverantörer fanns i en av de städer där ditt företag för närvarande har ett kontor. Du kan ställa in en CHECK-begränsning direkt på stadskolumnen, men det kan bli svårt att ändra den senare om ditt företag till exempel öppnar andra avdelningar där. Alternativt kan du skapa en vy som exkluderar ogiltiga stadsvärden: CREATE VIEW Curcities AS SELECT * FRÅN Säljare WHERE city IN ("London", "Rom", "San Jose", "Berlin") MED KONTROLLVALTNING; Nu, istället för att ge användarna ändringsprivilegier i säljartabellen, kan du ge dem i vyn Curcities. Fördelen med detta tillvägagångssätt är att om du behöver göra en ändring kan du ta bort den vyn, skapa en ny och ge användarna behörigheter i den nya vyn, vilket är enklare än att ändra begränsningar. Nackdelen är att ägaren av tabellen Försäljning också måste använda denna vy om han inte vill att hans egna kommandon ska avvisas. Å andra sidan tillåter detta tillvägagångssätt tabellägaren och alla andra att få modifieringsprivilegier på själva bordet, snarare än på vyn, för att göra undantag från begränsningar.

Detta är ofta önskvärt, men inte genomförbart om du använder begränsningar på basbordet. Tyvärr kommer dessa undantag inte att synas i vyn. Om du väljer det här tillvägagångssättet vill du skapa en andra vy som endast innehåller undantag: SKAPA VY Övriga städer SOM VÄLJ * FRÅN Säljare WHERE city NOT IN ("London", "Rom", "San Jose", "Berlin") MED KONTROLLERA ALTERNATIV; Du bör välja att bara ge användarna SELECT-privilegiet i den här vyn så att de kan se de uteslutna raderna men inte kan lägga in ogiltiga stadsvärden i den underliggande tabellen. Faktum är att användare kunde fråga båda vyerna i en union och se alla rader samtidigt.

ANDRA TYPER AV PRIVILEGIER

Naturligtvis vill du veta vem som har rätt att skapa tabellen först. Detta privilegieområde är inte ANSI, men kan inte ignoreras. Alla ANSI-standardbehörigheter härleds från detta privilegium; privilegier för tabellskapare som kan överföra objektprivilegier. Om alla dina användare skapar bastabeller i systemet med olika storlekar detta kommer att leda till redundans i dem och till ineffektivitet i systemet. Andra frågor väcker också uppmärksamhet:

Vem har rätt att ändra, ta bort eller begränsa tabeller?

Bör rättigheterna att skapa bastabeller skilja sig från rättigheterna att skapa vyer?

Ska det finnas en superanvändare - en användare som ansvarar för underhållet av databasen och därför har de flesta, eller alla, privilegier som inte beviljas individuellt?

Förrän ANSI är inblandat och SQL används i en mängd olika miljöer kan vi inte ge ett definitivt svar på dessa frågor. Vi föreslår att här överväga en del av de mest allmänna slutsatserna.

Privilegier som inte är definierade i termer av speciella dataobjekt kallas systemprivilegier, eller databasrättigheter. På en grundläggande nivå kommer dessa sannolikt att inkludera rätten att skapa dataobjekt, troligen andra än bastabeller (vanligtvis skapade av ett fåtal användare) och vyer (vanligtvis skapade av en majoritet av användarna). Systemprivilegier för att skapa vyer bör vara utöver, och inte i stället för, de objektbehörigheter som ANSI kräver av vyskapare (beskrivs tidigare i det här kapitlet). Dessutom, i ett system av vilken storlek som helst, finns det alltid vissa typer av superanvändare - användare som automatiskt har de flesta eller alla privilegier - och som kan överföra sin superanvändarstatus till någon annan genom ett privilegium eller en grupp av privilegier. Databasadministratör, eller DBA, är den term som oftast används för en sådan superanvändare och de privilegier den har.

TYPISKA SYSTEMPRIVILEGIER

I ett allmänt tillvägagångssätt finns det tre grundläggande systemprivilegier: - CONNECT, - RESOURCE och - DBA (Databas Administrator). I enklare termer kan CONNECT sägas bestå av rätten att registrera och rätten att skapa vyer och synonymer (se kapitel 23) om objektets privilegier passeras. RESOURCE består av rätten att skapa bastabeller. DBA är ett superanvändarprivilegium som ger användaren hög auktoritet i databasen. En eller flera användare med databasadministratörsfunktioner kan ha denna behörighet. Vissa system har också en speciell användare, ibland kallad SYSADM eller SYS (System Database Administrator), som har den högsta auktoriteten; det är speciellt för dem, och inte bara en användare med speciell DBA-behörighet. Faktum är att endast en person får registrera sig med namnet SYSADM, vilket är deras åtkomst-ID. Skillnaden är ganska subtil och fungerar olika i olika system. För våra syften kommer vi att hänvisa till en mycket privilegierad användare som utvecklar och hanterar en databas med DBA-behörigheter, med förståelse för att dessa privilegier faktiskt är samma privilegier. GRANT-kommandot, i modifierad form, är användbart med objektprivilegier såväl som systemprivilegier. Till att börja med kan överlåtelse av rättigheter göras med hjälp av en DBA. Till exempel kan en DBA ge Rodriguez behörighet att skapa bord enligt följande: GANTA RESURS TILL Rodriguez;

SKAPA OCH RADERA ANVÄNDARE

Naturligtvis uppstår frågan: var kommer en användare som heter Rodriguez ifrån? Hur bestämmer man dess clearance-ID? I de flesta implementeringar skapar DBA användaren genom att automatiskt ge honom CONNECT-privilegiet. I det här fallet läggs vanligtvis en IDENTIFIED BY-sats till för att indikera lösenordet. (Om inte måste operativsystemet avgöra om du kan logga in i databasen med det angivna åtkomst-ID.) DBA kan till exempel utfärda GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon; som kommer att skapa en användare som heter Thelonius, ge honom rätt att registrera sig och tilldela honom lösenordet Redwagon, allt i en mening. Eftersom Thelonious redan är en autentiserad användare kan han eller DBA använda samma kommando för att ändra Redwagons lösenord. Även om detta är bekvämt, finns det fortfarande begränsningar i detta tillvägagångssätt. Detta är omöjligheten att ha en användare som inte kunde registrera sig, åtminstone tillfälligt. Om du vill hindra en användare från att logga in måste du använda CONNECT-privilegiet på REVOKE, vilket "tar bort" den användaren. Vissa implementeringar låter dig skapa och ta bort användare, oavsett deras inloggningsprivilegier. När du beviljar CONNECT-behörigheten till en användare skapar du den användaren. För att göra detta själv måste du dessutom ha DBA-behörighet. Om den här användaren ska skapa bastabeller (inte bara vyer), måste han också beviljas RESOURCE-behörigheten. Men detta ger genast upphov till ett annat problem. Om du försöker ta bort CONNECT-privilegiet för en användare som har tabeller skapade av honom, kommer kommandot att avvisas eftersom det skulle lämna bordet utan en ägare, vilket inte är tillåtet. Du måste först släppa alla tabeller som skapats av den här användaren innan du tar bort hans CONNECT-behörighet. Om dessa tabeller inte är tomma, kommer du förmodligen att vilja skicka deras data till andra tabeller med kommandot INSERT, som använder en fråga. Du behöver inte ta bort RESOURSE-privilegiet separat; Det räcker att ta bort CONNECT för att ta bort användaren. Även om ovanstående är ett ganska standardsätt för systemprivilegier, har det också betydande begränsningar. Alternativa tillvägagångssätt har dykt upp som är mer specifikt definierade och kontrollera systemprivilegier mer exakt.

Dessa slutsatser tar oss något bortom SQL-standarden som för närvarande definieras, och i vissa implementeringar kan de gå bortom SQL-standarden helt. Dessa saker kommer förmodligen inte att bekymra dig så mycket om du inte är en DBA eller användare hög nivå. Regelbundna användare behöver helt enkelt vara bekanta med systemets privilegier i princip och konsultera deras dokumentation endast i händelse av speciella meddelanden.

SAMMANFATTNING

Behörigheter ger dig möjligheten att se SQL från ett nytt perspektiv när SQL utför åtgärder genom speciella användare på ett speciellt databassystem. Själva GRANT-kommandot är ganska enkelt: med dess hjälp ger du vissa privilegier för ett objekt till en eller flera användare. Om du beviljar privilegiet WITH GRANT OPTION till en användare, kan den användaren i sin tur bevilja privilegiet till andra. Du förstår nu tipsen om att använda privilegier på vyer – för att förbättra privilegier i bastabeller, eller som ett alternativ till begränsningar – och några av fördelarna och nackdelarna med detta tillvägagångssätt. Systemprivilegier som krävs men som inte ligger inom ramen för SQL-standarden har diskuterats i sin mest generella form och du kommer att lära dig dem genom övning. Kapitel 23 kommer att fortsätta diskussionen om slutledning i SQL, som att spara eller återställa ändringar, skapa egna namn för tabeller som ägs av andra människor och förstå vad som händer när olika användare försöker komma åt samma objekt samtidigt.

ARBETA MED SQL

1. Ge Janet rätt att ändra kundens betyg.

2. Ge Stephan rätten att ge andra användare rätten att göra frågor i ordertabellen.

3. Ta bort INSERT-behörigheten i tabellen Leverantörer från Claire och från alla användare som den beviljades.

4. Ge Jerry rätten att infoga eller modifiera Kundtabellen samtidigt som han behåller sin förmåga att utvärdera värden i intervallet 100 till 500.

5. Tillåt Janet att fråga i kundtabellen, men hindra henne från att sänka betyg i samma kundtabell.

SQL Server-plattformen använder REVOKE-satsen som ett sätt att återkalla behörighetsinställningarna som tilldelats en viss användare. Denna punkt är viktig eftersom SQL Server stöder en ytterligare DENY-sats som uttryckligen nekar en användare åtkomst till en angiven resurs. I SQL Server kan REVOKE-satsen användas för att återkalla privilegier som tilldelats en användare med GRANT-satsen. Om du uttryckligen vill neka en användare en viss behörighet, bör du använda DENY-satsen.

SQL Server-plattformen stöder inte satserna ANSI HIERARCHY OPTION och ADMIN OPTION. Även om ADMIN OPTION-satsen inte stöds, har SQL Server-versionen av kommandot REVOKE två administrativa behörigheter (CREATE och BACKUP). Instruktionssyntaxen är som följer.

REVOKE ([object_privilege] [, ...] | [system_privilege]) [(kolumn [, ...])]]| (TO | FROM) (mottagarens namn [, …] | roll [, …] | OFFENTLIGT | GÄST) ]

BIDRAG ALTERNATIV FÖR

Användaren fråntas rätten att tilldela specifika privilegier till andra användare.

objektprivilegium

Åtkomsträtten till olika instruktioner, som kan kombineras i valfri ordning, återkallas.

ALLT

Alla rättigheter tilldelade i för närvarande specificerade användare och/eller för specificerade databasobjekt. Detta förslag avråds eftersom det främjar tvetydighet i programmeringen.

(VÄLJ | INFOGA DELETE UPPDATERING)

Den angivna användaren nekas den angivna åtkomstbehörigheten för det angivna objektet (till exempel en tabell eller vy). För att återkalla privilegier på kolumnnivå, använd en lista med kolumner inom parentes.

REFERENSER

Rätten att skapa och ta bort främmande nyckelbegränsningar som refererar till ett databasobjekt som ett överordnat objekt återkallas.

Användarens rätt att skapa eller ta bort en regel i en tabell eller vy återkallas.

Rätten att utföra en lagrad procedur, användardefinierad funktion eller utökad lagrad procedur återkallas.

systembehörighet

Rätten att exekvera följande satser återkallas: SKAPA DATABAS, SKAPA STANDARD, SKAPA FUNKTION, SKAPA PROCEDUR, SKAPA REGEL, SKAPA TABELL, SKAPA VY, SÄKERHETSDATABAS och LOGG FÖR SÄKERHETSKOPI.

PÅ [objekt] [(kolumn [, ...])]

Användarens åtkomsträtt till det angivna objektet återkallas. Om objektet är en tabell eller vy kan du återkalla åtkomstbehörigheter för enskilda kolumner. Du kan återkalla privilegierna SELECT, INSERT, UPDATE, DELETE och REFERENCES på en tabell eller vy. På tabell- eller vykolumner kan du bara återkalla SELECT- och UPDATE-privilegier. Du kan återkalla EXECUTE-privilegier i en lagrad procedur, användardefinierad funktion eller utökad lagrad procedur.

[TILL | FROM] mottagarens namn | roll | OFFENTLIGT | GÄST

Anger de användare eller roller som förlorar den angivna behörigheten. Du kan använda nyckelordet PUBLIC för att återkalla privilegier som tilldelats rollen PUBLIC (som inkluderar alla användare). Du kan lista flera mottagare, separera deras namn med kommatecken. Stöds även i SQL Server konto GÄST, som används av alla användare som inte har en egen post i databasen.

Behörigheterna för användare som fått sina rättigheter genom WITH GRANT OPTION-klausulen tas bort. Denna klausul krävs när du använder GRANT OPTION FOR-satsen.

AS (gruppnamn rollnamn)

De rättigheter under vilka privilegiet återkallas anges. I vissa fall kan en användare tillfälligt behöva rättigheterna för en specifik grupp för att åsidosätta de angivna behörigheterna. I det här fallet kan du använda AS-klausulen för att erhålla sådana rättigheter.

De två formerna av REVOKE-satsen, REVOKE object privilege och REVOKE system_privilege, utesluter varandra. Försök inte att göra båda operationerna i ett påstående. Den viktigaste syntaktiska skillnaden mellan de två är att du inte ska använda ON-klausulen när du tar bort systemprivilegier. Till exempel, för att ta bort en systembehörighet, kan du använda följande kommando.

REVOKE SKAPA DATABAS, SÄKERHETSKOPIERA DATABAS FRÅN dylan, katie

Om privilegier tilldelades en användare som använder WITH GRANT OPTION-klausulen, bör dessa privilegier återkallas med samtidig användning av två satser - WITH GRANT OPTION och CASCADE. Till exempel:

ÅTERVÄLLA BEVILJANDEALTERNATIV FÖR VÄLJ, INFOGA, UPPDATERA, RADERA PÅ titlar TILL redaktörer CASCADE GO

Kommandot REVOKE kan endast användas på den aktuella databasen. Följaktligen antas ANSI-standardalternativen CURRENTJJSER och CURRENTROLE alltid implicit. REVOKE-satsen används också för att avbryta alla DENY-alternativ.

SQL Server-plattformen stöder också en ytterligare DENY-sats. Syntaxen för DENY-satsen är identisk med syntaxen för REVOKE-satsen. Men i huvudsak skiljer de sig åt genom att REVOKE neutraliserar användarens privilegier, medan DENY uttryckligen förbjuder dem. Använd DENY-satsen för att neka en användare eller roll åtkomst till ett privilegium, även om privilegiet beviljas uttryckligen eller genom rolltilldelning.

REVOKE-satsen måste användas för att ta bort tidigare beviljade eller DENY-privilegier. Användaren Kelly gick till exempel på förlängd mammaledighet. Under denna tid nekades hennes tillgång till arbetsbordet. Hon återvände och vi tillät privilegier igen.

NEKA ALLA PÅ anställd TILL Kelly GO

REVOKE ALL ON anställda TILL Kelly GO

I det här exemplet tar inte kommandot REVOKE bort hennes privilegier, det åsidosätter kommandot DENY.

Att skapa en användare ger inte i sig användaren några rättigheter att komma åt databasobjekt.

Behörigheter ges av kommandot GRANT. Man bör komma ihåg att användaren som utfärdar GRANT-kommandot kan överföra eller, om du föredrar, delegera till andra användare endast de rättigheter som han själv har.

GRANT anger rättigheter för databasobjekt till användare, roller eller andra databasobjekt. När ett objekt skapas är det bara dess skapare som har rättigheter till det, och endast han kan ge rättigheter till andra användare eller objekt.

För att komma åt en tabell eller vy behöver användaren eller objektet SELECT-, INSERT-, UPDATE-, DELETE- eller REFERENCES-rättigheter. Alla rättigheter kan ges med alternativet ALLA.

För att anropa en procedur i en applikation måste användaren ha EXECUTE-rättigheter.

Användare kan få tillstånd att ge rättigheter till andra användare genom att överföra rättigheter enligt listan , som specificeras av alternativet WITH GRANT OPTION. Användaren kan ge andra endast de rättigheter som han själv har.

Behörigheter kan ges till alla användare genom att använda alternativet PUBLIC i stället för listan med användarnamn. Att ange alternativet PUBLIC påverkar endast användare, inte databasobjekt.

Listan över rättigheter ges i tabell. 8.5.

Tabell 8.5. Lista över rättigheter

Rättigheter kan återkallas av användaren som beviljade dem med kommandot REVOKE. Om rättigheter utfärdades med ALL, kan de endast likvideras i ALL-läge; om rättigheter utfärdades med PUBLIC, kan de endast likvideras i OFFENTLIGT läge.

Syntax:

BILDA (alla /PRIVILEGES] / LJST_ ) PÅ BORD ]

(tabellnamn/visningsnamn)

TILL(