Tildeling og fjerning av rettigheter. Angi tillatelser grant-kommando Bruke visninger til å filtrere privilegier

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] PÅ (tbl_name | * | *.* | db_name.*) TIL brukernavn "passord"] [, brukernavn ...] ] ] ] ] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] PÅ (tbl_name | * | *.* | db_name.*) FROM user_name [, brukernavn ...]

GRANT er inkludert i MySQL versjon 3.22.11 og høyere. I tidligere versjoner av MySQL gjør GRANT-setningen ingenting.

GRANT- og REVOKE-kommandoene lar systemadministratorer opprette MySQL-brukere og gi eller tilbakekalle rettigheter til brukere på fire nivåer av privilegier:

Globalt nivå Globale privilegier gjelder for alle databaser på den angitte serveren. Disse privilegiene er lagret i mysql.user-tabellen. Databasenivå Databaserettigheter gjelder for alle tabeller i den angitte databasen. Disse rettighetene er lagret i tabellene mysql.db og mysql.host. Bordnivå Tabellrettigheter gjelder for alle kolonnene i den angitte tabellen. Disse privilegiene er lagret i tabellen mysql.tables_priv. Kolonnenivå Kolonnerettigheter gjelder for individuelle kolonner i den angitte tabellen. Disse privilegiene er lagret i tabellen mysql.columns_priv.

Hvis privilegier gis til en bruker som ikke eksisterer, opprettes denne brukeren. For eksempler på GRANT-kommandoen, se avsnitt 4.3.5 Legge til nye brukere til MySQL.

Tabellen viser en liste over mulige verdier for parameteren priv_type for GRANT- og REVOKE-setningene:

ALLE	Angir alle enkle privilegier bortsett fra MED TILDELINGSALTERNATIV
ENDRE	Tillater bruk av ALTER TABLE
SKAPE	Tillater bruk av CREATE TABLE
LAG MIDLERTIDIGE BORD	Tillater bruk av CREATE MIDLERTIDIG TABELL
SLETT	Tillater bruk av DELETE
MISTE	Tillater bruk av DROP TABLE.
HENRETTE	Lar brukeren kjøre lagrede prosedyrer (for MySQL 5.0)
FIL	Tillater bruk av SELECT ... INTO OUTFILE og LOAD DATA INFILE .
INDEKS	Tillater bruk av CREATE INDEX og DROPPE INDEKS
SETT INN	Tillater bruk av INSERT
LÅSE BORD	Tillater bruk av LOCK TABLES på tabeller som har SELECT-rettigheten.
PROSESS	Tillater bruk av VIS FULL PROSESSLISTE
REFERANSER	Reservert for fremtidig bruk
LAST OPP	Tillater bruk av FLUSH
REPLIKASJONSKLIENT	Gir brukeren rett til å spørre plasseringen til master- og slaveservere.
REPLIKASJONSSLAVE	Nødvendig for slaveservere under replikering (for å lese informasjon fra de binære loggene til hovedserveren).
PLUKKE UT	Tillater bruk av SELECT
VIS DATABASER	VIS DATABASER Viser alle databaser.
SKRU AV	Tillater bruk av mysqladmin-avslutning
SUPER	Lar deg opprette én tilkobling (én gang), selv om max_connections er nådd, og kjøre CHANGE MASTER , KILL thread , mysqladmin debug , PURGE MASTER LOGS og SET GLOBAL kommandoer
OPPDATER	Tillater bruk av UPDATE
BRUK	Synonym for ``uten privilegier''.

USAGE-verdien kan spesifiseres hvis du trenger å opprette en bruker uten privilegier.

Oppretting av midlertidige tabeller, UTFØR, LÅS TABELLER, REPLIKASJON ..., VIS DATABASER og SUPER-privilegier er nye i versjon 4.0.2. For å dra nytte av disse nye rettighetene etter oppgradering til versjon 4.0.2, må du kjøre mysql_fix_privilege_tables-skriptet.

I eldre versjoner av MySQL gir PROCESS-privilegiet de samme rettighetene som det nye SUPER-privilegiet.

For å tilbakekalle en brukers privilegier gitt av GRANT-kommandoen, bruk verdien priv_type i GRANT OPTION:

Mysql> REVOKE TILDELINGSOPTION PÅ ... FRA ...;

De eneste priv_type-verdiene som kan spesifiseres for en tabell er: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, IDEX og ALTER.

De eneste priv_type-verdiene som kan spesifiseres for en kolonne (når du bruker column_list-operatoren) er SELECT , INSERT og UPDATE .

Globale privilegier kan angis ved å bruke ON *.*-syntaksen, og databaseprivilegier kan angis ved å bruke ON db_name.*-syntaksen. Hvis du spesifiserer PÅ * mens gjeldende database er åpen, vil privilegier bli satt for den databasen. ( Advarsel: hvis du angir PÅ * når fravær gjeldende database er åpen, dette vil påvirke globale privilegier!)

For å kunne definere rettigheter for brukere på spesifikke datamaskiner, gir MySQL muligheten til å spesifisere brukernavnet (brukernavn) i skjemaet. Hvis du trenger å spesifisere en brukerstreng som inneholder spesialtegn (som "-"), eller en vertsstreng som inneholder spesialtegn eller jokertegn (som "%"), kan du legge ved navnet ekstern datamaskin eller bruker i anførselstegn (for eksempel "test-bruker"@"test-vertsnavn").

Du kan også inkludere jokertegn i navnet på den eksterne datamaskinen. For eksempel refererer "%.loc.gov" til brukeren av alle eksterne datamaskiner i loc.gov-domenet, og "144.155.166.%" refererer til brukeren av alle eksterne datamaskiner i klasse C-undernettet 144.155.166.

Den enkle skjemabrukeren er et synonym for "%" .

MySQL støtter ikke jokertegn i brukernavn. Anonyme brukere defineres ved å sette inn User=""-poster i mysql.user-tabellen eller ved å opprette en bruker med et tomt navn ved å bruke GRANT-kommandoen.

Merk: Hvis anonyme brukere har lov til å koble til MySQL-serveren, må du også gi privilegier til alle lokale brukere som , fordi ellers, når en bruker prøver å logge på MySQL fra den lokale datamaskinen, vil mysql.user-tabellen bruke den anonyme brukeren Logg Inn!

For å sjekke om dette skjer på datamaskinen din, kjør følgende spørring:

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

For øyeblikket støtter GRANT-kommandoen navn på eksterne datamaskiner, tabeller, databaser og kolonner på opptil 60 tegn. Brukernavnet må ikke inneholde mer enn 16 tegn.

Privilegier for en tabell eller kolonne dannes ved å bruke den logiske OR-operatoren fra privilegiene på hvert av de fire nivåene. For eksempel, hvis mysql.user-tabellen indikerer at brukeren har den globale SELECT-rettigheten, oppheves ikke denne rettigheten på database-, tabell- eller kolonnenivå.

Rettighetene for en kolonne kan beregnes som følger:

Globale privilegier ELLER (databaseprivilegier OG eksterne datamaskinprivilegier) ELLER tabellprivilegier ELLER kolonneprivilegier

I de fleste tilfeller er brukerrettigheter definert på bare ett rettighetsnivå, så denne prosedyren er vanligvis ikke så kompleks som beskrevet ovenfor. detaljert informasjon Rekkefølgen av handlinger for å kontrollere rettigheter er presentert i avsnitt 4.2 Generelle sikkerhetsproblemer og MySQL tilgangsrettighetssystem.

Hvis privilegier gis til en bruker/ekstern-kombinasjon som ikke er i mysql.user-tabellen, legges en oppføring til mysql.user-tabellen og forblir i tabellen til den slettes ved hjelp av DELETE-kommandoen. Med andre ord kan GRANT-kommandoen opprette brukerposter i tabellen, men REVOKE-kommandoen kan ikke slette dem. Dette må gjøres ved å bruke DELETE-kommandoen.

Hvis du har databaserettigheter, opprettes en oppføring i tabellen mysql.db om nødvendig. Denne oppføringen slettes etter at alle privilegier for denne databasen er fjernet med REVOKE-kommandoen.

Hvis en bruker ikke har noen rettigheter på en tabell, vises ikke tabellen når brukeren ber om en liste over tabeller (for eksempel ved å bruke SHOW TABLES-setningen).

WITH GRANT OPTION-setningen gir en bruker muligheten til å gi andre brukere alle rettigheter han selv har på et spesifisert rettighetsnivå. Forsiktighet må utvises når du gir GRANT-privilegiet, da to brukere med forskjellige privilegier kan kombinere privilegiene sine!

Alternativene MAX_QUERIES_PER_HOUR # , MAX_UPDATES_PER_HOUR # og MAX_CONNECTIONS_PER_HOUR # er nye i MySQL versjon 4.0.2. Disse innstillingene begrenser antall forespørsler, oppdateringer og pålogginger som en bruker kan gjøre i løpet av én time. Hvis satt til 0 (standard), betyr dette at det ikke er noen begrensninger for denne brukeren. Se avsnitt.

Du kan ikke gi en annen bruker et privilegium som du ikke har. GRANT-privilegiet lar deg gi bare de privilegiene du har.

Merk at hvis en bruker er tildelt GRANT-rettigheten på et bestemt rettighetsnivå, kan alle rettigheter som den brukeren allerede har (eller vil bli tildelt i fremtiden!) på det nivået også tildeles den brukeren. La oss anta at en bruker har fått INSERT-rettighet på en database. Hvis du deretter gir SELECT-privilegiet i databasen og spesifiserer WITH GRANT OPTION, kan brukeren gi ikke bare SELECT-privilegiet, men også INSERT-privilegiet. Hvis du deretter gir brukeren UPDATE-rettigheten i databasen, kan brukeren utstede INSERT, SELECT og UPDATE.

ALTER-privilegier bør ikke tildeles vanlige brukere. Dette gir brukeren muligheten til å bryte privilegiesystemet ved å gi nytt navn til tabeller!

Vær oppmerksom på at hvis tabell- eller kolonneprivilegier brukes for én bruker, sjekker serveren tabell- og kolonneprivilegiene for alle brukere, og dette bremser MySQL noe.

Når mysqld starter, leses alle privilegier inn i minnet. Database-, tabell- og kolonneprivilegier trer i kraft umiddelbart, mens rettigheter på brukernivå trer i kraft neste gang brukeren kobler til. Endringer i rettighetstildelingstabellene som er gjort ved hjelp av GRANT- og REVOKE-kommandoene behandles umiddelbart av serveren. Hvis du endrer rettighetstildelingstabeller manuelt (ved å bruke INSERT , UPDATE , etc.), må du kjøre FLUSH PRIVILEGES eller mysqladmin flush-privilege s-setningen for å instruere serveren om å laste inn rettighetstildelingstabellene på nytt. Se avsnitt 4.3.3 Når rettighetsendringer trer i kraft.

De viktigste forskjellene mellom ANSI SQL- og MySQL-versjonene av GRANT-kommandoen er som følger:

• I MySQL er privilegier tildelt kombinasjonen av brukernavn + ekstern datamaskin, ikke bare brukernavnet.
• ANSI SQL har ikke globale privilegier eller privilegier på databasenivå, og ANSI SQL støtter ikke alle MySQL privilegietyper. MySQL, på den annen side, støtter ikke ANSI SQL TRIGGER, EXECUTE eller UNDER-privilegiene.
• ANSI SQL-rettighetsstrukturen er hierarkisk. Hvis du sletter en bruker, oppheves alle rettigheter som er tildelt denne brukeren. I MySQL oppheves ikke tildelte privilegier automatisk, du må fjerne dem selv om nødvendig.
• I MySQL kan en bruker SETTE INN en tabell hvis de har INSERT-rettigheter på bare noen få kolonner i den tabellen. Kolonner som ikke har INSERT-rettigheten vil bli satt til standardverdiene. ANSI SQL krever INSERT-rettigheter på alle kolonner.
• Når du slipper en tabell i ANSI SQL, vil alle rettigheter for den tabellen bli opphevet. Hvis du tilbakekaller et privilegium i ANSI SQL, tilbakekalles også alle privilegier som ble tildelt basert på det privilegiet. I MySQL kan privilegier bare fjernes ved å bruke REVOKE-kommandoen eller ved å endre MySQL-rettighetstildelingstabellene.

For en beskrivelse av bruk av REQUIRE, se avsnitt 4.3.9 Bruke sikre tilkoblinger.

Brukerkommentarer

Skrevet av Frank Wortner

[Slett] [Rediger]

Jeg hadde ingen problemer med ld. DEC (Compaq) kanskje
har fikset ld i et lappesett. Du vil kanskje
installer det nyeste oppdateringssettet for din Digital Unix
(Tru64 Unix) før du bygger MySQL. Lappesett
er tilgjengelig på
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Skrevet av lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

For kildeinstallasjoner refererer disse instruksjonene til katalogstrukturen forutsatt at "usr/local" ble brukt (standard) med configure. Men instruksjonene på forrige side (for kompilering/installasjon) foreslår at du bruker:

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

For å være konsekvent (og dette forårsaker meg noen problemer med Perl, så det er ikke rent semantisk), bør instruksjonene på denne siden anta at /usr/local/mysql ble spesifisert som installasjonsmappen med configure.

Skrevet av Linda Wright lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

Dette er nok det viktigste og minst
verdsatte deler av hele mySQL
dokumentasjon for førstegangsbrukere av mySQL. IMHO,
les denne siden i forbindelse med
http://www.mysql.com/doc/P/r/Privileges.html er en
må for planlegging av alle sikre databasesystemer
av noen virkelig raffinement.

Skrevet av Christopher Raymond lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

Jeg prøver å installere MySQL under OS X Public Beta. Når jeg kjører mysql_install_db-skriptet, får jeg en feilmelding:

Dyld: ./bin/mysqld kan ikke åpne biblioteket: /usr/lib/libpthread.A.dylib (Ingen slik fil eller katalog, errno = 2)
Installasjon av tilskuddstabeller mislyktes!

Jeg antar at skriptet leter etter en katalog som ikke eksisterer fordi Apple har en litt annen katalognavnstruktur. Kanskje dette skriptet må endres for OS X-distribusjonen.

Kan noen hjelpe?

Skrevet av Mark Zieg lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

Det ville vært fint om det var et alternativ for å logge tilkoblinger, men ikke spørringer.

Skrevet av Bennett Haselton lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

Hvis du er logget på som mysql root-bruker, uten at en gjeldende database er valgt, og du prøver å
gi alle rettigheter til en bruker med kommandoen:

GIR ALLE PRIVILEGIER PÅ * TIL bhaselto

Da vil ikke RELOAD, SHUTDOWN, PROCESS, FILE og GRANT bli gitt, som kan være
verifisert ved å sjekke "bruker"-tabellen i "mysql"-databasen. (Dette er antagelig av design,
siden disse privilegiene kan gjøre en bruker "for kraftig".)

Skrevet av DC Hill lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

MERK: Hvis du har gitt rettigheter til en bruker på en bestemt database, eller på et hvilket som helst lavere nivå enn det, ved å påkalle "REVOKE ALL ON *.* FROM ;" vil IKKE trekke tilbake privilegier på disse nivåene. *.* i setningen ovenfor betyr "global", ikke "alle (individuelle) tabeller på alle (individuelle) databaser. Den erklæringen vil KUN tilbakekalle globale privilegier, som lagret i mysql.user-tabellen. Du MÅ tilbakekalle noen mer spesifikke privilegier på samme måte som de ble gitt, hvis du ønsker at de skal fjernes fra privilegietabellene. (dvs. - GIR ALLE ON foo.* TO ; => REVOKE ALL ON foo.* FROM ;) Jeg håper dette sparer noen av du litt tid og frustrasjon.

Skrevet av Cris Perdue lørdag 16. februar 2002, klokken 22:21

[Slett] [Rediger]

"Hvis du har prosessprivilegiet, kan du se
alle tråder.
Ellers kan du bare se dine egne tråder."

Skrevet av FreeBSD Forums lørdag 16. februar 2002, @22:21

[Slett] [Rediger]

Du kan bruke phpMyAdmin nettbasert verktøy for å gjøre mye
av mySQL admin funksjoner. href="http://www.freebsdforums.org"
>FreeBSD-fora

Skrevet av mandag 25. februar 2002, kl. 06:03

[Slett] [Rediger]

Verifisert på MySQL 3.23.36 på Red Hat Linux 7.1:
Merk at hvis du skriver
bruk a_c;
gi velg på * til ;
du vil få tilgang til evt
database som samsvarer med "a_c" der understreken er en
jokertegn. (Sjelden et problem, antar jeg).
Rett opp med
oppdater mysql.db set db="a\_c" hvor db="a_c";

Skrevet av jan behrens tirsdag 9. juli 2002, klokken 01:31

[Slett] [Rediger]

den nevnte feilen fra DAN ELIN i x.x.41 er
tilsynelatende fortsatt gyldig i x.x.51, jeg kan ikke logge på en
database etter å ha gitt privilegier og gitt en
passord til en ny bruker (ja, jeg tømte
privilegier).............kun root-tilgang er mulig

Skrevet av Dan Egli torsdag 4. april 2002, klokken 20:33

[Slett] [Rediger]

Det ser ut til å være en feil i 3.23.41 som bruker Grant.
Bare root kan få tilgang til mysql-databasen, til og med
etter å ha brukt Grant til å gi privs på hva som helst
database/tabell/kolonne/ect.. får du alltid
tillatelse nektet, uansett.

Skrevet av Lars Aronsson lørdag 8. juni 2002, klokken 11:16

["%". Når jeg prøver å slette dem, får jeg beskjed om en viss database, men ingen globale privilegier OPPRETT MIDLERTIDIG TABELL-privilegium på den databasen blir nektet. Du må gi global CREATE __and__ global LAG MIDLERTIDIGE TABELLER til brukeren. IOW: GITT OPPRETT, OPPRETT MIDLERTIDIGE TABELLER PÅ *.* TIL ; Unødvendig å si, dette påvirker sikkerheten takknemlig. Skrevet av søndag 25. august 2002, kl. 09:17 [Slett] [Rediger] Midlertidige filer er en god idé, men selv med Opprett og opprett midlertidige filrettigheter i brukerfil (globale rettigheter) fungerer det fortsatt ikke. Dette ser ut til å være dårlig utformet. Skrevet av Brad Bulger mandag 2. september 2002, klokken 04:09 [Slett] [Rediger] Det skal bemerkes at kun MED TILSKUDD lar brukeren gi privilegier videre til brukere som Finnes allerede. Den automagiske opprettelsen av brukeren poster gjør ikke søke - du får en feilmelding som brukeren med GRANT OPTION-rettigheten gjør har ikke tilgang til "mysql"-databasen. Dette er sannsynligvis en god ting, men det må dokumenteres. Skrevet av Michael Babcock fredag ​​8. november 2002, klokken 13:00 [Slett] [Rediger] VIS MASTER STATUS krever PROSESS-rettigheter. Andre slike odde kombinasjoner bør dokumenteres. Skrevet av Dee Kintaudi torsdag 21. november 2002, klokken 12:42 [Slett] [Rediger] Ok, jeg har et spørsmål og et problem med Mysql og passord:). Jeg prøvde å bruke flere av alternativene og de fleste av dem har ikke fungert. Imidlertid en løsningen fungerte og jeg testet den ut to ganger og den var solid. Selvfølgelig mistet jeg den lille lappen jeg skrev det ut på og jeg kan ikke finne dette løsning hvor som helst, som om den ikke eksisterte eller kanskje jeg innbilte det. Løsningen som fungerte for meg, før jeg mistet den lille lapperen jeg skrev den ned på går noe sånt som dette..... Sett inn i brukerrot Passord "mitt passord" og så noe med "Y", "Y", "Y", (omtrent et dusin eller 15 ganger eller så) Jeg kan imidlertid ikke finne denne løsningen noe sted noen som hjelper meg her? Jeg tror det ville vært så fint om de bare la dette gjennom hele dokumentasjonen i stedet for å prøve Gjem det. Jeg tror dette vil løse mange problemer. Bare sette passord = "Y", "Y", "Y", det er som om de skammer seg over det eller noe. Skrevet av AJIT DIXIT mandag 25. november 2002, klokken 06:56 [Slett] [Rediger] Når jeg jobber med flerbordsoppdatering med root-bruker det fungerer fint Når jeg jobber med en ikke-root bruker får jeg feilmelding SQL: oppdater lagerførere, områder satt a_nm = aname hvor acd = areal

I dette kapittelet lærer du hvordan du arbeider med privilegier. Som diskutert i kapittel 2, brukes SQL vanligvis i miljøer som krever brukergjenkjenning og skille mellom ulike brukere av systemer. Generelt sett oppretter databaseadministratorer selv brukere og gir dem privilegier. På den annen side har brukere som lager tabeller selv rettigheter til å administrere disse tabellene. Privilegier er det som avgjør om en spesifisert bruker kan utføre en gitt kommando. Det finnes flere typer privilegier som tilsvarer flere typer operasjoner. Privilegier gis og tilbakekalles ved hjelp av to SQL-kommandoer: - GRANT og REVOKE. Dette kapittelet vil vise deg hvordan disse kommandoene brukes.

BRUKERE

Hver bruker i et SQL-miljø har et spesielt identifikasjonsnavn eller -nummer. Terminologien er forskjellig overalt, men vi har valgt (etter ANSI) å referere til den eller nummeret som Access Identifier (ID). En kommando sendt til databasen er knyttet til en spesifikk bruker; eller på annen måte, en spesiell tilgangsidentifikator. Når det gjelder en SQL-database, er tillatelses-IDen brukernavnet, og SQL kan bruke det spesielle nøkkelordet USER, som refererer til tilgangs-IDen som er knyttet til den gjeldende kommandoen. Kommandoen tolkes og tillates (eller nektes) basert på informasjon knyttet til tilgangs-IDen til brukeren som utsteder kommandoen.

REGISTRERING

I systemer med mange brukere er det en slags innloggingsprosedyre som brukeren må gjennomføre for å få tilgang til datasystemet. Denne prosedyren bestemmer hvilken tilgangs-ID som skal knyttes til gjeldende bruker. Vanligvis må hver person som bruker databasen ha sin egen tilgangs-ID og blir ved registrering en gyldig bruker. Imidlertid kan ofte brukere med mange oppgaver registreres under ulike tilgangs-IDer, eller omvendt kan én tilgangs-ID brukes av flere brukere. Fra et SQL-perspektiv er det ingen forskjell mellom disse to tilfellene; den behandler brukeren ganske enkelt som deres tilgangs-ID. SQL-databasen kan bruke sin egen påloggingsprosedyre, eller den kan tillate et annet program, som f.eks operativsystem(hovedprogrammet som kjører på datamaskinen din), behandle registreringsfilen og få tilgangs-ID fra dette programmet. På en eller annen måte vil SQL ha en tilgangs-ID som kan knyttes til handlingene dine, og USER nøkkelordet vil være relevant for deg.

GI PRIVILEGIER

Hver bruker i en SQL-database har et sett med privilegier. Dette er hva brukeren har lov til å gjøre (kanskje det er en loggfil, som kan betraktes som et minimumsprivilegium). Disse privilegiene kan endres over tid - nye legges til, gamle fjernes. Noen av disse privilegiene er definert i ANSI SQL, men det er ekstra privilegier som også kreves. SQL-privilegier som definert av ANSI er ikke tilstrekkelige i de fleste virkelige situasjoner. På den annen side kan typene privilegier som er nødvendig variere med typen system du bruker - som ANSI ikke gir noen anbefalinger for. Privilegier som ikke er en del av SQL-standarden kan bruke syntaks som er lik og ikke helt i samsvar med standarden.

STANDARDPRIVILEGIER

SQL-privilegier definert av ANSI er objektprivilegier. Dette betyr at brukeren har rettigheten til å utføre en gitt kommando kun på et spesifikt objekt i databasen. Det er klart at privilegier må skille mellom disse objektene, men et privilegiesystem basert utelukkende på et objekts privilegier kan ikke adressere alt som SQL trenger, som vi vil se senere i dette kapittelet. Et objekts privilegier er knyttet til både brukere og tabeller. Det vil si at rettigheten gis til en spesifikk bruker i en spesifisert tabell, eller underliggende tabell eller visning. Du må huske at brukeren som opprettet tabellen (av noe slag) er eieren av denne tabellen.

Dette betyr at brukeren har alle rettighetene i denne tabellen og kan overføre rettigheter til andre brukere i denne tabellen. Rettigheter som kan tildeles en bruker:

VELG En bruker med denne rettigheten kan kjøre spørringer på tabellen.

INSERT En bruker med dette privilegiet kan gi en INSERT-kommando på en tabell.

OPPDATERING En bruker med denne rettigheten kan gi en OPPDATERING-kommando på en tabell. Du kan begrense dette privilegiet til bestemte tabellkolonner.

SLETT En bruker med dette privilegiet kan gi en DELETE-kommando på en tabell.

REFERANSER En bruker med dette privilegiet kan definere en fremmednøkkel som bruker en eller flere kolonner i denne tabellen som en overordnet nøkkel. Du kan begrense dette privilegiet til visse kolonner. (Se kapittel 19 for detaljer om fremmednøkkel og overordnet nøkkel.)

I tillegg vil du møte ikke-standard objektprivilegier, som INDEX, som gir rett til å lage en indeks på en tabell, SYNONYM, som gir rett til å lage et synonym for et objekt, som vil bli forklart i kapittel 23, og ALTER, som gir rett til å utføre ALTER TABLE-kommandoen på en tabell. SQL-motoren tildeler disse rettighetene til brukere som bruker GRANT-kommandoen.

GRANNT TEAM

La oss anta at brukeren Diane har en kundetabell og ønsker å la brukeren Adrian spørre etter den. Diane bør deretter skrive inn følgende kommando:

STILLE INNSERT PÅ Selgere TIL Diane;

Nå kan Adrian kjøre spørringer mot Kunder-tabellen. Uten andre privilegier kan han bare velge verdier; men kan ikke utføre noen handling som vil påvirke verdiene i Kunder-tabellen (inkludert bruk av Kunder-tabellen som overordnet tabell for fremmednøkkelen, som begrenser endringene som kan gjøres i verdien i Kunder-tabellen).

Når SQL mottar en GRANT-kommando, sjekker den privilegiene til brukeren som utsteder kommandoen for å finne ut om GRANT-kommandoen er gyldig. Adrian kan ikke gi denne kommandoen på egen hånd. Den kan heller ikke gi SELECT-tillatelse til en annen bruker: tabellen tilhører fortsatt Diane (vi viser senere hvordan Diane kan gi Adrian SELECT-tillatelse til andre brukere).

Syntaksen er den samme som for å gi andre privilegier. Hvis Adrian er eieren av selgertabellen, kan han tillate Diane å legge inn rader i den ved å bruke følgende klausul

STILLE INNSERT PÅ Selgere TIL Diane; Diane har nå rett til å plassere en ny selger i tabellen.

PRIVILEGIER GRUPPER, BRUKERGRUPPER

Du bør ikke begrense deg til å gi et enkelt privilegium til en individuell bruker med GRANT-kommandoen. Kommaseparerte lister over privilegier eller brukere er helt akseptable. Stephen kan gi både SELECT og INSERT i ordretabellen for Adrian

GRANT SELECT, SETT INN PÅ bestillinger TIL Adrian; eller for både Adrian og Diane GRANNT SELECT, SETT INN PÅ bestillinger TIL Adrian, Diane;

Når privilegier og brukere er oppført på denne måten, gis hele listen over privilegier til alle spesifiserte brukere. I streng ANSI-tolkning kan du ikke gi privilegier på mange tabeller samtidig med en enkelt kommando, men noen implementeringer kan lempe på denne begrensningen ved å la deg spesifisere flere tabeller, atskilt med kommaer, slik at hele listen over privilegier kan gis for alle spesifiserte tabeller..

BEGRENSNING AV PRIVILEGIER PÅ SPESIFIKKE KOLONNER

Alle objektprivilegier bruker samme syntaks, bortsett fra kommandoene UPDATE og REGERNCES, som ikke krever kolonnenavn. OPPDATERING-privilegiet kan gis som andre privilegier:

GI OPPDATERING PÅ selgere TIL Diane;

Denne kommandoen lar Diane endre verdiene i hvilken som helst eller alle kolonnene i leverandørtabellen. Men hvis Adrian ønsker å begrense Diane fra å endre for eksempel provisjoner, kan han gå inn

GI OPPDATERING (komm) PÅ selgere TIL Diane;

Med andre ord, den må ganske enkelt spesifisere den spesifikke kolonnen som UPDATE-rettigheten skal brukes på, i parentes etter tabellnavnet. Navnene på flere tabellkolonner kan spesifiseres i hvilken som helst rekkefølge, atskilt med komma:

GI OPPDATERING (by, kommunikasjon) PÅ selgere TIL Diane;

REFERANSER følger samme regel. Når du gir REFERENCES-rettigheten til en annen bruker, vil de kunne opprette fremmednøkler som refererer til kolonner i tabellen som overordnede nøkler. I likhet med UPDATE, kan REFERENCES-rettigheten spesifiseres som en liste over én eller flere kolonner som det privilegiet er begrenset for. Diane kan for eksempel gi Stephen rett til å bruke kundetabellen som overordnet nøkkeltabell med følgende kommando:

GIR REFERANSER (cname, cnum) PÅ kunder TIL Stephen; Denne kommandoen gir Stephen rett til å bruke kolonnene cnum og cname som overordnede nøkler til alle fremmednøkler i tabellene hans. Stephen kan kontrollere hvordan dette gjøres. Den kan definere (cname, cnum) eller, i vårt tilfelle, (cnum, cname), som en to-kolonne overordnet nøkkel matchet av en fremmednøkkel til to kolonner i en av sine egne tabeller. Eller den kan lage separate fremmednøkler for å referere til kjønn individuelt, og dermed sikre at Diane har en overordnet nøkkel tilordnet den (se kapittel 19).

Uten restriksjoner på fremmednøkkelnumre, må den være basert på disse overordnede nøklene, og foreldrenøklene til forskjellige fremmednøkler må få lov til å overlappe.

Som med UPDATE-privilegiet kan du ekskludere en liste over kolonner og dermed tillate at alle kolonner brukes som overordnede nøkler. Adrian kan gi Diane rett til å gjøre dette med følgende kommando:

GIR REFERANSER OM selgere TIL Diane;

Naturligvis vil rettigheten kun være brukbar på kolonner som har begrensningene som kreves av overordnede nøkler.

BRUKER ALLE OG OFFENTLIGE ARGUMENT

SQL støtter to argumenter til GRANT-kommandoen som har en spesiell betydning: ALL PRIVILEGES, eller ganske enkelt ALL og PUBLIC. ALL brukes i stedet for rettighetsnavn i GRANT-kommandoen for å gi alle rettigheter i en tabell. For eksempel kan Diane gi Stephen hele settet med privilegier i Kunder-tabellen med følgende kommando:

GIR REFERANSER OM selgere TIL Diane;

(UPDATE- og REFERANSER-privilegiene gjelder naturligvis for alle kolonner.) Her er en annen måte å si det samme på:

GIR ALT PÅ kunder TIL Stephen;

PUBLIC er mer som en catch-all-argumenttype enn et brukerprivilegium. Når du gir publiseringsrettigheter, mottar alle brukere dem automatisk. Oftest brukes dette for SELECT-privilegiet på visse underliggende tabeller eller visninger som du ønsker å gjøre tilgjengelig for enhver bruker. For å la enhver bruker se bestillingstabellen, kan du for eksempel skrive inn følgende:

GI UTVALG PÅ BESTILLINGER TIL OFFENTLIGHET;

Selvfølgelig kan du gi noen eller alle privilegiene til samfunnet, men dette er sannsynligvis ikke tilrådelig. Alle privilegier unntatt SELECT lar brukeren endre (eller, i tilfelle REFERANSER, begrense) innholdet i tabellen. Å tillate alle brukere å endre innholdet i tabellene dine vil forårsake et problem.

Selv om du har et lite selskap og alle dine nåværende brukere er i stand til å utføre modifikasjonskommandoer på en gitt tabell, ville det være bedre å gi privilegier til hver bruker individuelt enn å gi de samme privilegiene til alle. PUBLIC er ikke begrenset til kun å overføre den til nåværende brukere. Noen Ny bruker lagt til systemet ditt vil automatisk motta alle privilegiene som tidligere er tildelt alle, så hvis du vil begrense tabelltilgang til alle, nå eller i fremtiden, er det best å gi andre privilegier enn SELECT til individuelle brukere.

GIR PRIVILEGIER VED Å BRUKE MED TILSKUDD

Noen ganger vil skaperen av et bord at andre brukere skal kunne få privilegier på bordet hans. Dette gjøres typisk i systemer der en eller flere personer lager flere (eller alle) av basistabellene i en database og deretter delegerer ansvaret for dem til de som faktisk skal jobbe med dem. SQL lar deg gjøre dette ved å bruke WITH GRANT OPTION-klausulen. Hvis Diane ønsket at Adrian skulle kunne gi SELECT-privilegiet på Customers-tabellen til andre brukere, ville hun gi ham SELECT-privilegiet ved å bruke WITH GRANT OPTION-klausulen:

GI UTVALG PÅ Kunder TIL Adrian MED TILSKUDSVALG; Adrian skaffet seg deretter retten til å overføre SELECT-privilegiet til tredjeparter; den kan gi kommandoen GRANT SELECT ON Diane.Customers TO Stephen; eller til og med GI UTVALG PÅ Diane.Kunder TIL Stephen MED TILSKUDSVALG; En bruker med et GRANTE-ALTERNATIV på et bestemt privilegium på et gitt bord kan på sin side gi det privilegiet på det samme bordet, med eller uten GANT-ALTERNATIV, til enhver annen bruker. Dette endrer ikke eierskapet til selve bordet; som før tilhører bordet dets skaper. (Derfor må tildelte brukere prefikse eiertilgangs-IDen når de refererer til disse tabellene. Neste kapittel vil vise deg denne metoden.) En bruker som bruker GRANT-ALTERNATIVET på alle privilegier for en gitt tabell vil ha full autoritet i den tabellen.

KANSELLERING AV PRIVILEGIER

Akkurat som ANSI gir kommandoen CREATE TABLE for å lage en tabell, i stedet for DROP TABLE-kommandoen for å bli kvitt den, lar GRANT-kommandoen deg gi privilegier til brukere uten å gi dem en måte å ta dem tilbake på. Behovet for å fjerne privilegier kommer ned til REVOKE-kommandoen, som faktisk er et standardverktøy med en ganske klar form for oppføring. Syntaksen til REVOKE-kommandoen ligner på GRANT, men har motsatt betydning. For å fjerne INSERT-privilegiet for Adrian i Order-tabellen, kan du gå inn

REVOKE INSERT PÅ bestillinger FRA Adrian;

Bruk av lister over privilegier og brukere er tillatt her som med GRANT, så du kan skrive inn følgende kommando:

OPPHAV INNLEGG, SLETT PÅ kunder FRA Adrian, Stephen; Det er imidlertid noe uklarhet her. Hvem har rett til å tilbakekalle privilegier? Når mister en bruker med rett til å overføre rettigheter til andre denne retten? Vil brukerne som han ga disse privilegiene også miste dem? Siden dette ikke er en standardfunksjon, er det ingen autoritative svar på disse spørsmålene, men den vanligste tilnærmingen er denne: * Privilegier tilbakekalles av brukeren som ga dem, og tilbakekallingen vil fosse sammen, det vil si at den automatisk forplanter seg til alle brukere som mottok rettigheten fra ham.

BRUKE VISNINGER FOR Å FILTRERE PRIVILEGIER

Du kan gjøre rettighetshandlinger mer presise ved å bruke visninger. Hver gang du gir en rettighet på en basistabell til en bruker, spres det automatisk til alle rader og, når du bruker de mulige unntakene OPPDATERING og REFERENSER, til alle kolonnene i tabellen. Ved å opprette en visning som refererer til den underliggende tabellen og deretter overføre privilegiet til visningen i stedet for tabellen, kan du begrense disse privilegiene til alle uttrykk i spørringen i visningen. Dette forbedrer de grunnleggende egenskapene til GRANT-kommandoen betraktelig.

HVEM KAN INNLEGG?

For å opprette en visning må du ha SELECT-privilegium på alle tabellene du refererer til i visningen. Hvis visningen kan endres, vil alle INSERT-, UPDATE- og DELETE-privilegier du har på basistabellen automatisk bli overført til visningen. Hvis du mangler endringsprivilegier på basistabellene, vil du ikke kunne ha dem på visningene du oppretter, selv om disse visningene i seg selv kan endres. Fordi fremmednøkler ikke brukes i visninger, brukes aldri REFERENCES-privilegiet når du oppretter visninger. Alle disse restriksjonene er definert av ANSI. Ikke-standard systemrettigheter (diskutert senere i dette kapittelet) kan også aktiveres. I de følgende avsnittene vil vi anta at skaperne av visningene vi diskuterer har private eller passende privilegier på alle underliggende tabeller.

BEGRENSNING AV VALGPRIVILEGE PÅ SPESIFIKKE KOLONNER

La oss si at du vil gi brukeren Claire muligheten til å se bare snum- og sname-kolonnene i Sales-tabellen. Du kan gjøre dette ved å legge inn navnene på disse kolonnene i visningen

CREATE VIEW Clairesview AS SELECT snum, sname FRA Selgere; og gi Claire SELECT-privilegiet på visningen i stedet for på selve selgerbordet: GANT SELECT On Clairesview til Claire; Du kan opprette privilegier spesifikt for kolonner, som å bruke andre privilegier, men for en INSERT-kommando vil dette sette inn standardverdier, og for en DELETE-kommando vil kolonnebegrensningen ikke ha noen effekt. REFERANSER og OPPDATERING-privilegier kan selvfølgelig gjøre kolonner spesifikke uten å ty til en visning.

BEGRENSNING AV PRIVILEGIER FOR SPESIFIKKE STRENGER Vanligvis er en mer nyttig måte å filtrere privilegier med visninger på å bruke visningen til å få privilegiet til å gjelde bare for bestemte rader. Dette gjør du naturlig ved å bruke et predikat på visningen som avgjør hvilke rader som er inkludert. For å gi brukeren Adrian UPDATE-rettigheten på Kunder-tabellen for alle kunder som befinner seg i London, kan du opprette en visning som denne:

LAG VISNING Londoncust AS VELG * FRA kunder HVOR by = "London" MED KONTROLLVALG; Du må da gi UPDATE-privilegiet på dette bordet til Adrian: GANT UPDATE ON Londoncust TO Adrian; Dette er forskjellen mellom privilegiet for visse rader og UPDATE-privilegiet for visse kolonner, som gjelder for alle kolonnene i Kunder-tabellen, men ikke for rader, blant hvilke rader med en annen kjønnsverdi enn London ikke vil bli tatt i betraktning . WITH CHECK OPTION-klausulen hindrer Adrian i å endre byens kjønnsverdi til noe annet enn London. GIR KUN TILGANG TIL UTTREKKTE DATA En annen mulighet er å tilby brukere tilgang til dataene som allerede er hentet, i stedet for de faktiske verdiene i tabellen. Aggregerte funksjoner kan være veldig praktiske ved bruk av denne metoden. Du kan opprette en visning som gir antall, gjennomsnitt og total for bestillinger for hver dag av bestillingen: CREATE VIEW Datototals AS SELECT odate, COUNT (*), SUM (amt), AVG (amt) FROM Orders GROUP BY odate; Du gir nå brukeren Diane SELECT-privilegiet på Datototals-visningen: GANT SELECT ON Datototals TO Diane; BRUKE REPRESENTASJONER SOM ET ALTERNATIV TIL BEGRENSNINGER En av de siste applikasjonene i serien, beskrevet i kapittel 18, er bruk av visninger med MED KONTROLLOPSJON som et alternativ til begrensninger. La oss si at du ville forsikre deg om at alle byens kjønnsverdier i leverandørtabellen var i en av byene der bedriften din for øyeblikket har et kontor. Du kan sette en CHECK-begrensning direkte på bykolonnen, men det kan bli vanskelig å endre den senere hvis bedriften for eksempel åpner andre avdelinger der. Alternativt kan du opprette en visning som ekskluderer ugyldige byverdier: CREATE VIEW Curcities AS SELECT * FRA Selgere WHERE city IN ("London", "Roma", "San Jose", "Berlin") MED KONTROLLVALG; Nå, i stedet for å gi brukere endringsprivilegier i selgertabellen, kan du gi dem i Curcities-visningen. Fordelen med denne tilnærmingen er at hvis du trenger å gjøre en endring, kan du slette den visningen, opprette en ny og gi privilegier til brukere i den nye visningen, noe som er enklere enn å endre begrensninger. Ulempen er at eieren av Salgstabellen også må bruke denne visningen dersom han ikke ønsker at egne kommandoer skal avvises. På den annen side lar denne tilnærmingen tabelleieren og alle andre få modifikasjonsprivilegier på selve bordet, i stedet for på visningen, for å gjøre unntak fra begrensninger.

Dette er ofte ønskelig, men ikke gjennomførbart hvis du bruker begrensninger på basisbordet. Disse unntakene vil dessverre ikke være synlige i visningen. Hvis du velger denne tilnærmingen, vil du lage en ekstra visning som kun inneholder unntak: LAG VISNING Andre byer SOM VELG * FRA Selgere HVOR byen IKKE er i ("London", "Roma", "San Jose", "Berlin") MED KONTROLLOPSJON; Du bør velge å gi brukerne kun SELECT-privilegiet på denne visningen, slik at de kan se de ekskluderte radene, men ikke kan sette ugyldige byverdier i den underliggende tabellen. Faktisk kan brukere spørre begge visningene i en union og se alle radene samtidig.

ANDRE TYPER PRIVILEGIER

Selvfølgelig vil du vite hvem som har rett til å lage bordet først. Dette privilegieområdet er ikke ANSI, men kan ikke ignoreres. Alle standard ANSI-privilegier er avledet fra dette privilegiet; privilegier til tabellskapere som kan overføre objektprivilegier. Hvis alle brukerne dine lager basistabeller i systemet med forskjellige størrelser dette vil føre til redundans i dem og til ineffektivitet av systemet. Andre spørsmål vekker også oppmerksomhet:

Hvem har rett til å endre, slette eller begrense tabeller?

Bør rettighetene til å lage basistabeller være forskjellige fra rettighetene til å lage visninger?

Skal det være en superbruker – en bruker som er ansvarlig for å vedlikeholde databasen og derfor har de fleste, eller alle, rettigheter som ikke er gitt individuelt?

Før ANSI er involvert og SQL brukes i en rekke miljøer, kan vi ikke gi et definitivt svar på disse spørsmålene. Vi foreslår å vurdere her en del av de mest generelle konklusjonene.

Privilegier som ikke er definert i form av spesielle dataobjekter kalles systemprivilegier, eller databaserettigheter. På et grunnleggende nivå vil disse sannsynligvis inkludere retten til å lage dataobjekter, sannsynligvis andre enn basistabeller (vanligvis opprettet av noen få brukere) og visninger (vanligvis opprettet av et flertall av brukere). Systemprivilegier for å lage visninger bør komme i tillegg til, og ikke i stedet for, objektprivilegiene som ANSI krever av visningsskapere (beskrevet tidligere i dette kapittelet). I tillegg, i et system av enhver størrelse er det alltid noen typer superbrukere - brukere som automatisk har de fleste eller alle privilegier - og som kan overføre superbrukerstatusen sin til noen andre gjennom et privilegium eller en gruppe privilegier. Database Administrator, eller DBA, er det begrepet som oftest brukes for en slik superbruker og rettighetene den har.

TYPISKE SYSTEMPRIVILEGIER

I en generell tilnærming er det tre grunnleggende systemprivilegier: - CONNECT, - RESOURCE, og - DBA (Database Administrator). Forenklet sett kan CONNECT sies å bestå av retten til å registrere seg og retten til å lage visninger og synonymer (se kapittel 23) dersom objektets privilegier er bestått. RESURSE består av retten til å lage basistabeller. DBA er et superbrukerprivilegium som gir brukeren høy autoritet i databasen. En eller flere brukere med datkan ha denne rettigheten. Noen systemer har også en spesiell bruker, noen ganger kalt SYSADM eller SYS (System Database Administrator), som har den høyeste autoriteten; det er spesielt for dem, og ikke bare en bruker med spesielle DBA-privilegier. Faktisk har bare én person lov til å registrere seg med navnet SYSADM, som er deres tilgangs-ID. Skillet er ganske subtilt og fungerer forskjellig i forskjellige systemer. For våre formål vil vi referere til en svært privilegert bruker som utvikler og administrerer en database med DBA-privilegier, og forstår at disse privilegiene faktisk er de samme privilegiene. GRANT-kommandoen, i modifisert form, kan brukes med objektprivilegier så vel som systemprivilegier. Til å begynne med kan overføring av rettigheter gjøres ved hjelp av en DBA. En DBA kan for eksempel gi Rodriguez rettigheter til å opprette bord på følgende måte: GIR RESURSE TIL Rodriguez;

OPPRETT OG SLETT BRUKERE

Naturligvis oppstår spørsmålet: hvor kommer en bruker ved navn Rodriguez fra? Hvordan bestemme dens klarerings-ID? I de fleste implementeringer oppretter DBA brukeren ved automatisk å gi ham CONNECT-privilegiet. I dette tilfellet legges vanligvis en IDENTIFIED BY-klausul til for å indikere passordet. (Hvis ikke, må operativsystemet avgjøre om du kan logge inn i databasen med gitt tilgangs-ID.) DBA kan for eksempel utstede GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon; som vil opprette en bruker ved navn Thelonius, gi ham rett til å registrere seg og tildele ham passordet Redwagon, alt i én setning. Siden Thelonious allerede er en autentisert bruker, kan han eller DBA bruke denne samme kommandoen til å endre Redwagons passord. Selv om dette er praktisk, er det fortsatt begrensninger i denne tilnærmingen. Dette er umuligheten av å ha en bruker som ikke kunne registrere seg, i hvert fall midlertidig. Hvis du vil hindre en bruker i å logge inn, må du bruke CONNECT-privilegiet på REVOKE, som "fjerner" denne brukeren. Noen implementeringer lar deg opprette og slette brukere, uavhengig av deres påloggingsrettigheter. Når du gir CONNECT-rettigheten til en bruker, oppretter du denne brukeren. Dessuten, for å gjøre dette selv, må du ha DBA-privilegium. Hvis denne brukeren skal lage basistabeller (ikke bare visninger), må han også gis RESOURCE-rettigheten. Men dette gir umiddelbart opphav til et annet problem. Hvis du prøver å fjerne CONNECT-privilegiet til en bruker som har tabeller opprettet av ham, vil kommandoen bli avvist fordi den ville forlate bordet uten en eier, noe som ikke er tillatt. Du må først droppe alle tabeller opprettet av denne brukeren før du fjerner CONNECT-rettigheten hans. Hvis disse tabellene ikke er tomme, vil du sannsynligvis sende dataene deres til andre tabeller ved å bruke INSERT-kommandoen, som bruker en spørring. Du trenger ikke å fjerne RESOURSE-privilegiet separat; Det er nok å slette CONNECT for å slette brukeren. Selv om ovennevnte er en ganske standard tilnærming til systemprivilegier, har den også betydelige begrensninger. Alternative tilnærminger har dukket opp som er mer spesifikt definert og kontroller systemprivilegier mer nøyaktig.

Disse konklusjonene tar oss noe utover SQL-standarden slik den er definert for øyeblikket, og i noen implementeringer kan de gå utover SQL-standarden helt. Disse tingene vil sannsynligvis ikke bekymre deg for mye med mindre du er en DBA eller bruker høy level. Vanlige brukere trenger bare å være kjent med systemets privilegier i prinsippet, og konsultere dokumentasjonen deres kun i tilfelle spesielle meldinger.

SAMMENDRAG

Privilegier gir deg muligheten til å se SQL fra et nytt perspektiv når SQL utfører handlinger gjennom spesielle brukere på et spesielt databasesystem. Selve GRANT-kommandoen er ganske enkel: med dens hjelp gir du visse privilegier til et objekt til en eller flere brukere. Hvis du gir WITH GRANT OPTION-privilegiet til en bruker, kan denne brukeren i sin tur gi det privilegiet til andre. Du forstår nå hintene om bruk av privilegier på visninger – for å forbedre rettigheter i basistabeller, eller som et alternativ til begrensninger – og noen av fordelene og ulempene med denne tilnærmingen. Systemprivilegier som kreves, men som ikke er innenfor rammen av SQL-standarden, har blitt diskutert i sin mest generelle form, og du vil lære dem gjennom praksis. Kapittel 23 vil fortsette diskusjonen om inferens i SQL, for eksempel å lagre eller gjenopprette endringer, lage dine egne navn for tabeller som eies av andre mennesker, og forstå hva som skjer når forskjellige brukere prøver å få tilgang til det samme objektet samtidig.

ARBEIDE MED SQL

1. Gi Janet rett til å endre kundens vurdering.

2. Gi Stephan rett til å gi andre brukere rett til å stille spørsmål i ordretabellen.

3. Fjern INSERT-rettigheten i leverandørtabellen fra Claire og fra alle brukere som den ble gitt til.

4. Gi Jerry rett til å sette inn eller endre kundetabellen mens han beholder sin evne til å evaluere verdier i området 100 til 500.

5. Tillat Janet å spørre i kundetabellen, men hindre henne i å redusere vurderinger i den samme kundetabellen.

SQL Server-plattformen bruker REVOKE-setningen som en måte å tilbakekalle tillatelsesinnstillingene som er tildelt en gitt bruker. Dette punktet er viktig fordi SQL Server støtter en ekstra DENY-setning som eksplisitt nekter en bruker tilgang til en spesifisert ressurs. I SQL Server kan REVOKE-setningen brukes til å tilbakekalle privilegier som er tildelt en bruker ved å bruke GRANT-setningen. Hvis du eksplisitt vil nekte en bruker et visst privilegium, bør du bruke DENY-setningen.

SQL Server-plattformen støtter ikke klausulene ANSI HIERARCHY OPTION og ADMIN OPTION. Selv om ADMIN OPTION-leddet ikke støttes, har SQL Server-versjonen av REVOKE-kommandoen to administrative rettigheter (CREATE og BACKUP). Instruksjonssyntaksen er som følger.

REVOKE ([object_privilege] [, ...] | [system_privilege]) [(kolonne [, ...])]]| (TO | FROM) (mottakernavn [, …] | rolle [, …] | OFFENTLIG | GJEST) ]

TILSKUDD VALG FOR

Brukeren fratas retten til å tildele spesifikke rettigheter til andre brukere.

objektrettighet

Adgangsrettigheter til ulike instruksjoner, som kan kombineres i hvilken som helst rekkefølge, oppheves.

ALLE

Alle privilegier tildelt i for tiden spesifiserte brukere og/eller for spesifiserte databaseobjekter. Dette forslaget frarådes fordi det fremmer tvetydighet i programmeringen.

(VELG | INSERT SLETT OPPDATERING)

Den spesifiserte brukeren nektes den angitte tilgangsrettigheten til det angitte objektet (for eksempel en tabell eller visning). For å tilbakekalle privilegier på kolonnenivå, bruk en liste over kolonner i parentes.

REFERANSER

Retten til å opprette og slette fremmednøkkelbegrensninger som refererer til et databaseobjekt som et overordnet objekt, oppheves.

Brukerens rett til å opprette eller slette en regel i en tabell eller visning oppheves.

Retten til å utføre en lagret prosedyre, brukerdefinert funksjon eller utvidet lagret prosedyre oppheves.

systemrettigheter

Retten til å utføre følgende setninger er opphevet: CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLE, CREATE VIEW, SACKUP DATABASE og SIKKERHETSIKKERHETSLOGG.

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

Brukerens tilgangsrett til det angitte objektet oppheves. Hvis objektet er en tabell eller visning, kan du tilbakekalle tilgangsrettigheter på individuelle kolonner. Du kan tilbakekalle rettighetene SELECT, INSERT, UPDATE, DELETE og REFERENCES på en tabell eller visning. På tabell- eller visningskolonner kan du bare tilbakekalle SELECT- og UPDATE-privilegier. Du kan tilbakekalle EXECUTE-rettigheter i en lagret prosedyre, brukerdefinert funksjon eller utvidet lagret prosedyre.

[TO | FROM] mottakernavn | rolle | OFFENTLIG | GJEST

Angir brukerne eller rollene som mister det angitte privilegiet. Du kan bruke nøkkelordet PUBLIC for å tilbakekalle privilegier som er tildelt rollen PUBLIC (som inkluderer alle brukere). Du kan liste opp flere mottakere, skille navnene deres med komma. Støttes også i SQL Server Regnskap GUEST, som brukes av alle brukere som ikke har egen oppføring i databasen.

Rettighetene til brukere som mottok rettighetene sine gjennom WITH GRANT OPTION-klausulen, fjernes. Denne klausulen er påkrevd når du bruker GRANT OPTION FOR-klausulen.

AS (gruppenavn rollenavn)

Rettighetene som privilegiet er tilbakekalt under, er angitt. I noen tilfeller kan en bruker midlertidig trenge rettighetene til en bestemt gruppe for å overstyre de angitte rettighetene. I dette tilfellet kan du bruke AS-klausulen for å oppnå slike rettigheter.

De to formene for REVOKE-setningen, REVOKE objektprivilegium og REVOKE system_privilege, utelukker hverandre. Ikke prøv å gjøre begge operasjonene i en uttalelse. Den viktigste syntaktiske forskjellen mellom de to er at du ikke bør bruke ON-klausulen når du fjerner systemprivilegier. For å fjerne et systemprivilegium kan du for eksempel bruke følgende kommando.

OPPHAV OPPRETT DATABASE, SIKKERHETSKOPIER DATABASE FRA dylan, katie

Hvis privilegier ble tildelt en bruker som bruker WITH GRANT OPTION-klausulen, bør disse privilegiene trekkes tilbake ved bruk av to klausuler samtidig - WITH GRANT OPTION og CASCADE. For eksempel:

OPPHAV TILDELINGSALTERNATIV FOR VELG, INSERT, OPPDATERING, SLETT PÅ titler TIL redaktører CASCADE GO

REVOKE-kommandoen kan bare brukes på gjeldende database. Følgelig er ANSI-standardalternativene CURRENTJJSER og CURRENTROLE alltid implisitt antatt. REVOKE-setningen brukes også til å kansellere alle DENY-alternativer.

SQL Server-plattformen støtter også en ekstra DENY-setning. Syntaksen til DENY-setningen er identisk med syntaksen til REVOKE-setningen. Imidlertid skiller de seg i hovedsak ved at REVOKE nøytraliserer brukerens privilegier, mens DENY eksplisitt forbyr dem. Bruk DENY-setningen til å nekte en bruker eller rolle tilgang til et privilegium, selv om privilegiet er gitt eksplisitt eller gjennom rolletildeling.

REVOKE-setningen må brukes til å fjerne tidligere tildelte eller DENY-rettigheter. For eksempel gikk bruker Kelly ut i utvidet svangerskapspermisjon. I løpet av denne tiden ble hennes tilgang til ansattbordet nektet. Hun kom tilbake og vi ga privilegier på nytt.

NEKTE ALLE PÅ ansatt TIL Kelly GO

TILBAKE ALT PÅ ansatte TIL Kelly GO

I dette eksemplet fjerner ikke REVOKE-kommandoen hennes privilegier; den overstyrer DENY-kommandoen.

Å opprette en bruker gir ikke i seg selv noen rettigheter til tilgang til databaseobjekter.

Tillatelser gis av GRANT-kommandoen. Det bør huskes at brukeren som utsteder GRANT-kommandoen kan overføre eller, hvis du foretrekker det, delegere til andre brukere kun de rettighetene han selv har.

GRANT setter rettigheter på databaseobjekter til brukere, roller eller andre databaseobjekter. Når et objekt er opprettet, er det bare skaperen som har rettigheter til det, og bare han kan gi rettigheter til andre brukere eller objekter.

For å få tilgang til en tabell eller visning trenger brukeren eller objektet rettighetene SELECT, INSERT, UPDATE, DELETE eller REFERENCES. Alle rettigheter kan gis med ALLE-alternativet.

For å kalle en prosedyre i en applikasjon må brukeren ha EXECUTE-rettigheter.

Brukere kan få tillatelse til å gi rettigheter til andre brukere ved å overføre rettigheter i henhold til listen , som er spesifisert av WITH GRANT OPTION-alternativet. Brukeren kan kun gi andre rettigheter han selv har.

Tillatelser kan gis til alle brukere ved å bruke PUBLIC-alternativet i stedet for listen over brukernavn. Å spesifisere alternativet PUBLIC påvirker bare brukere, ikke databaseobjekter.

Listen over rettigheter er gitt i tabell. 8.5.

Tabell 8.5. Liste over rettigheter

Rettigheter kan tilbakekalles av brukeren som ga dem ved å bruke REVOKE-kommandoen. Hvis rettigheter ble utstedt ved bruk av ALL, kan de bare likvideres i ALL-modus; hvis rettigheter ble utstedt ved bruk av OFFENTLIG, kan de bare likvideres i OFFENTLIG modus.

Syntaks:

GRANTE (alle /PRIVILEGES] / LJST_ ) PÅ BORDET ]

(tabellnavn/visningsnavn)

TIL(