Доделување и отстранување права. Поставување дозволи команда за доделување Користење на прегледи за филтрирање на привилегии

ГРАНТИРАЈ priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) TO user_name "password"] [, user_name ...] ] ] ] РЕВОКИРАЈ го приватен_тип [(список_колона)] [, приватен_тип [(список_колона)] ...] ВКЛУЧЕНО (tbl_име | * | *.* | db_име.*) ОД корисничко_име [, корисничко_име ...]

GRANT е вклучен во MySQL верзија 3.22.11 и понова. Во претходните верзии на MySQL, изјавата GRANT не прави ништо.

Наредбите GRANT и REVOKE им дозволуваат на системските администратори да креираат MySQL корисници и да доделуваат или одземаат права на корисниците на четири нивоа на привилегии:

Глобално нивоГлобалните привилегии важат за сите бази на податоци на наведениот сервер. Овие привилегии се зачувани во табелата mysql.user. Ниво на база на податоциПривилегиите на базата на податоци важат за сите табели во наведената база на податоци. Овие привилегии се зачувани во табелите mysql.db и mysql.host. Ниво на масаПривилегиите за табелите важат за сите колони од наведената табела. Овие привилегии се зачувани во табелата mysql.tables_priv. Ниво на колонаПривилегиите на колоните важат за поединечни колони во наведената табела. Овие привилегии се зачувани во табелата mysql.columns_priv.

Ако се доделуваат привилегии на корисник кој не постои, тогаш тој корисник се креира. За примери на командата GRANT, видете го делот 4.3.5 Додавање нови корисници во MySQL.

Табелата покажува список на можни вредности за параметарот priv_type за изјавите GRANT и REVOKE:

СИТЕ	Ги поставува сите едноставни привилегии освен СО ОПЦИЈА ЗА ГРАНТ
АЛТЕР	Дозволува употреба на ALTER TABLE
КРЕИРАЈ	Дозволува употреба на CREATE TABLE
КРЕИРАЈ ПРИВРЕМЕНИ ТАБЕЛИ	Дозволува употреба на КРЕИРАЈ ПРИВРЕМЕНА ТАБЕЛА
ИЗБРИШИ	Дозволува употреба на DELETE
КАПКА	Дозволува употреба на DROP TABLE.
ИЗВРШИ	Дозволува корисникот да извршува зачувани процедури (за MySQL 5.0)
ДАТОТЕКА	Дозволува употреба на ИЗБЕРИ ... ВО ИЗЛЕЗНАТА ДАТОТЕЈКА и ВКЛУЧИ ИНФОРМАЦИЈА ПОДАТОЦИ .
ИНДЕКС	Дозволува употреба на КРЕИРАЈ ИНДЕКС и КАПНИИНДЕКС
ВНЕСЕТЕ	Дозволува употреба на INSERT
ЗАКЛУЧЕТЕ МАСИ	Дозволува употреба на LOCK TABLES на табели кои имаат привилегија SELECT.
ПРОЦЕС	Дозволува употреба на ПОКАЖИ ЦЕЛОСНА ЛИСТА НА ПРОЦЕСИ
РЕФЕРЕНЦИ	Резервирано за идна употреба
ПРЕВТОРИРАЈТЕ	Дозволува употреба на FLUSH
КЛИЕНТ ЗА РЕПЛИКАЦИЈА	Му дава право на корисникот да ја бара локацијата на главниот и серверот slave.
РЕПЛИКАЦИЈА СЛАВ	Неопходно е за slave сервери при репликација (за читање информации од бинарните дневници на главниот сервер).
ИЗБЕРИ	Дозволува употреба на SELECT
ПОКАЖИ БАЗИ НА ПОДАТОЦИ	ПОКАЖИ БАЗИ НА ПОДАТОЦИ Ги наведува сите бази на податоци.
ИСКЛУЧИ	Дозволува употреба на исклучување на mysqladmin
СУПЕР	Ви овозможува да воспоставите една врска (еднаш), дури и ако се постигне max_connections, и да извршите CHANGE MASTER , KILL thread , mysqladmin debug , PURGE MASTER LOGS и SET GLOBAL команди
АЖУРИРАЈ	Дозволува употреба на АЖУРИРАЊЕ
КОРИСТЕЊЕ	Синоним за „без привилегии“.

Вредноста КОРИСТЕЊЕ може да се наведе ако треба да креирате корисник без привилегии.

Привилегиите КРЕИРАЈ ПРИВРЕМЕНИ ТАБЕЛИ, ИЗВРШЕЊЕ, ЗАКЛУЧУВАЊЕ ТАБЕЛИ, РЕПЛИКАЦИЈА..., ПОКАЖУВАЈ БАЗИ НА ПОДАТОЦИ и СУПЕР се нови во верзијата 4.0.2. За да ги искористите овие нови привилегии по надградбата на верзијата 4.0.2, мора да ја извршите скриптата mysql_fix_privilege_tables.

Во постарите верзии на MySQL, привилегијата PROCESS ги дава истите права како и новата SUPER привилегија.

За да ги отповикате привилегиите на корисникот дадени со командата GRANT, користете ја вредноста priv_type во ОПЦИЈАТА GRANT:

Mysql> ОПИШАЊЕ НА ГРАНТ ОПЦИЈА НА ... ОД ...;

Единствените вредности на priv_type кои можат да се наведат за табела се: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, IDEX и ALTER.

Единствените вредности на priv_type што може да се наведат за колона (кога се користи операторот со листа на колони) се SELECT , INSERT и UPDATE .

Глобалните привилегии може да се постават со помош на синтаксата ON *.*, а привилегиите за базата на податоци може да се постават со помош на синтаксата ON db_name.*. Ако наведете ON * додека тековната база на податоци е отворена, ќе се постават привилегии за таа база на податоци. ( Предупредување: ако наведете ON * кога отсуствотековната база на податоци е отворена, ова ќе влијае на глобалните привилегии!)

За да може да се дефинираат правата за корисниците на одредени компјутери, MySQL обезбедува можност да го наведе корисничкото име (user_name) во формуларот. Ако треба да наведете корисничка низа што содржи специјални знаци (како што се `-“) или низа домаќин што содржи специјални или џокални знаци (како што е `%“), можете да го приложите името далечински компјутерили корисник во наводници (на пример, „test-user“@“test-hostname“).

Може да вклучите и џокери во името на далечинскиот компјутер. На пример, „%.loc.gov“ се однесува на корисникот на сите оддалечени компјутери во доменот loc.gov, а „144.155.166.%“ се однесува на корисникот на сите оддалечени компјутери во класата C подмрежа 144.155.166.

Корисникот на едноставна форма е синоним за „%“.

MySQL не поддржува џокери во корисничките имиња. Анонимните корисници се дефинираат со вметнување на записи User="" во табелата mysql.user или со креирање на корисник со празно име со помош на командата GRANT.

Забелешка: Ако на анонимните корисници им е дозволено да се поврзат со серверот MySQL, мора да им дадете и привилегии на сите локални корисници како , бидејќи во спротивно, кога корисникот се обидува да се најави на MySQL од локалниот компјутер, табелата mysql.user ќе го користи анонимниот корисник Логирај Се!

За да проверите дали ова се случува на вашиот компјутер, извршете го следново барање:

Mysql> ИЗБЕРЕТЕ Домаќин, Корисник ОД mysql.user WHERE Корисник="";

Во моментов, командата GRANT поддржува имиња на оддалечени компјутери, табели, бази на податоци и колони до 60 знаци. Корисничкото име мора да содржи не повеќе од 16 знаци.

Привилегиите за табела или колона се формираат со помош на логичкиот ИЛИ оператор од привилегиите на секое од четирите нивоа. На пример, ако табелата mysql.user покажува дека корисникот ја има глобалната привилегија SELECT, таа привилегија не се укинува на ниво на база на податоци, табела или колона.

Привилегиите за колона може да се пресметаат на следниов начин:

Глобални привилегии ИЛИ (привилегии на база на податоци И привилегии за далечински компјутер) ИЛИ привилегии на табелата ИЛИ привилегии на колона

Во повеќето случаи, корисничките права се дефинирани на само едно ниво на привилегии, така што оваа постапка обично не е толку сложена како што е опишано погоре. детални информацииРедоследот на дејства за проверка на привилегиите е претставен во делот 4.2 Општи безбедносни прашања и системот за привилегии за пристап MySQL.

Ако се доделуваат привилегии на корисничка/оддалечена комбинација што не е во табелата mysql.user, се додава запис во табелата mysql.user и останува во табелата додека не се избрише со помош на командата DELETE. Со други зборови, командата GRANT може да креира кориснички записи во табелата, но командата REVOKE не може да ги избрише. Ова мора да се направи со помош на командата DELETE.

Ако имате привилегии за базата на податоци, доколку е потребно се креира запис во табелата mysql.db. Овој запис се брише откако ќе се отстранат сите привилегии за оваа база на податоци со командата REVOKE.

Ако корисникот нема никакви привилегии на табелата, тогаш табелата не се прикажува кога корисникот бара листа на табели (на пример, користејќи ја изјавата SHOW TABLES).

Изјавата WITH GRANT OPTION му дава можност на корисникот да им даде на други корисници какви било привилегии што тој самиот ги има на одредено ниво на привилегии. Мора да се внимава при доделувањето на привилегијата ГРАНТ, бидејќи двајца корисници со различни привилегии може да ги комбинираат своите привилегии!

Опциите MAX_QUERIES_PER_HOUR #, MAX_UPDATES_PER_HOUR # и MAX_CONNECTIONS_PER_HOUR # се нови во верзијата 4.0.2 на MySQL. Овие поставки го ограничуваат бројот на барања, ажурирања и најавувања што корисникот може да ги направи за еден час. Ако е поставено на 0 (стандардно), тоа значи дека нема ограничувања за овој корисник. Видете го делот.

Не можете да му дадете на друг корисник привилегија што ја немате. Привилегијата GRANT ви овозможува да ги дадете само оние привилегии што ги имате.

Забележете дека ако на корисникот му е доделена GRANT привилегијата на одредено ниво на привилегија, тогаш сите привилегии што тој корисник веќе ги има (или ќе му бидат доделени во иднина!) на тоа ниво, исто така, може да му се доделат на тој корисник. Да претпоставиме дека на корисникот му е доделена привилегија INSERT во базата на податоци. Ако потоа ја доделите привилегијата SELECT во базата на податоци и наведете WITH GRANT OPTION, корисникот може да даде не само привилегија SELECT, туку и привилегија INSERT. Ако потоа му ја доделите на корисникот привилегија АЖУРИРАЊЕ во базата на податоци, корисникот потоа може да издаде INSERT, SELECT и UPDATE.

Привилегиите на ALTER не треба да им се доделуваат на редовните корисници. Ова му дава на корисникот можност да го прекине системот за привилегии со преименување на табелите!

Ве молиме имајте предвид дека ако привилегиите за табели или колони се користат дури и за еден корисник, серверот ги проверува привилегиите за табелата и колоните за сите корисници и тоа донекаде го забавува MySQL.

Кога ќе започне mysqld, сите привилегии се читаат во меморијата. Привилегиите за базата на податоци, табелите и колоните стапуваат на сила веднаш, додека привилегиите на ниво на корисник стапуваат на сила следниот пат кога корисникот ќе се поврзе. Промените на табелите за доделување привилегии што се направени со помош на командите GRANT и REVOKE се обработуваат веднаш од серверот. Ако рачно ги менувате табелите за доделување привилегии (користејќи INSERT , UPDATE итн.), мора да ја извршите изјавата FLUSH PRIVILEGES или mysqladmin flush-privilege за да му наложите на серверот повторно да ги вчита табелите за доделување привилегии. Видете дел 4.3.3 Кога ќе стапат на сила промените на привилегиите.

Најзначајните разлики помеѓу верзиите ANSI SQL и MySQL на командата GRANT се како што следува:

• Во MySQL, привилегиите се доделуваат на комбинацијата на корисничко име + оддалечен компјутер, а не само на корисничкото име.
• ANSI SQL нема глобални или привилегии на ниво на база на податоци, а ANSI SQL не ги поддржува сите типови на MySQL привилегии. MySQL, од друга страна, не ги поддржува привилегиите ANSI SQL TRIGGER, EXECUTE или UNDER.
• Структурата на привилегии на ANSI SQL е хиерархиска. Ако избришете корисник, сите привилегии доделени на тој корисник се укинуваат. Во MySQL, доделените привилегии не се автоматски одземени; мора сами да ги отстраните доколку е потребно.
• Во MySQL, корисникот може да вметне табела ако има INSERT привилегија само на неколку колони во таа табела. Колоните што немаат привилегија INSERT ќе бидат поставени на нивните стандардни вредности. ANSI SQL бара INSERT привилегија на сите колони.
• Кога ќе испуштите табела во ANSI SQL, сите привилегии за таа табела ќе бидат укинати. Ако отповикате привилегија во ANSI SQL, сите привилегии што беа доделени врз основа на таа привилегија се исто така отповикани. Во MySQL, привилегиите може да се отстранат само со помош на командата REVOKE или со менување на табелите за доделување привилегии на MySQL.

За опис на користењето REQUIRE, видете во делот 4.3.9 Користење на безбедни врски.

Коментари на корисниците

Објавено од Френк Вортнер

[Избриши] [Уреди]

Немав проблеми со лд. DEC (Compaq) може
имаат поправено ld во комплет за закрпи. Можеби ќе сакате
инсталирајте го најновиот комплет за закрпи за вашиот Digital Unix
(Tru64 Unix) пред да се изгради MySQL. Сетови за лепенки
се достапни на
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Објавено од во сабота, 16 февруари 2002, @22:21

[Избриши] [Уреди]

За изворни инсталации, овие инструкции се однесуваат на структурата на директориумот со претпоставка дека „usr/local“ се користел (стандардно) при конфигурирање. Но, упатствата на претходната страница (за компилација/инсталација) предлагаат да користите:

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

За да бидам конзистентен (и ова ми предизвикува некои проблеми со Perl, па затоа не е чисто семантички), инструкциите на оваа страница треба да претпоставуваат дека /usr/local/mysql е наведен како директориум за инсталација со конфигурирање.

Објавено од Линда Рајт во сабота, 16 февруари 2002 година, @22:21

[Избриши] [Уреди]

Ова е веројатно најважното и најмалку
ценети делови од целиот mySQL
документација за првпат корисници на mySQL. ИМХО,
читање на оваа страница во врска со
http://www.mysql.com/doc/P/r/Privileges.html е
мора за планирање на кој било безбедни системи за бази на податоци
од секаква вистинска софистицираност.

Испратено од Кристофер Рејмонд во сабота, 16 февруари 2002 година, @ 22:21

[Избриши] [Уреди]

Се обидувам да инсталирам MySQL под OS X Public Beta. Кога ја извршувам скриптата mysql_install_db, добивам порака за грешка:

Dyld: ./bin/mysqld не може да ја отвори библиотеката: /usr/lib/libpthread.A.dylib (Нема таква датотека или директориум, errno = 2)
Инсталирањето на табелите за грантови не успеа!

Претпоставувам дека скриптата бара директориум што не постои бидејќи Apple има малку поинаква структура за именување директориум. Можеби оваа скрипта треба да се измени за дистрибуцијата на OS X.

Може ли некој да помогне?

Објавено од Марк Зиг во сабота, 16 февруари 2002 година, @22:21

[Избриши] [Уреди]

Би било убаво да има опција за логирање врски, но не и прашања.

Објавено од Бенет Хејзелтон во сабота, 16 февруари 2002 година, @ 22:21

[Избриши] [Уреди]

Ако сте најавени како root корисник на mysql, без избрана моментална база на податоци, и се обидете да го направите тоа
дајте ги сите привилегии на корисникот со командата:

ДАДЕТЕ ГИ СИТЕ ПРИВИЛЕГИИ НА * НА bhaselto

Тогаш RELOAD, SHUTDOWN, PROCESS, FILE и GRANT нема да бидат доделени, како што може да биде
потврдено со проверка на табелата „корисник“ на базата на податоци „mysql“. (Ова е веројатно по дизајн,
бидејќи овие привилегии може да го направат корисникот „премногу моќен“.)

Објавено од DC Hill во сабота, 16 февруари 2002 година, @22:21

[Избриши] [Уреди]

ЗАБЕЛЕШКА: Ако сте доделиле привилегии на корисник на одредена база на податоци или на кое било пониско ниво од тоа, повикувајќи се на „REVOKE ALL ON *.* FROM ;“ НЕМА да ги укине привилегиите на тие нивоа. *.* во горната изјава значи „глобална“, а не „сите (индивидуални) табели на сите (поединечни) бази на податоци. Таа изјава САМО ќе ги укине глобалните привилегии, складирани во табелата mysql.user. МОРА да отповикате која било поконкретна привилегиите на ист начин како што беа дадени, доколку сакате тие да бидат отстранети од табелите за привилегии. (т.е. - ГРАНТ СИТЕ НА foo.* TO ; => REVOKE ALL ON foo.* FROM ;) Се надевам дека ова ќе заштеди некои од ти малку време и фрустрација.

Испратено од Крис Пердју во сабота, 16 февруари 2002 година, @22:21

[Избриши] [Уреди]

„Ако имате привилегија за процесот, можете да видите
сите нишки.
Во спротивно, можете да ги видите само вашите сопствени нишки“.

Објавено од Форумите на FreeBSD во сабота, 16 февруари 2002, @22:21

[Избриши] [Уреди]

Можете да користите phpMyAdmin веб-базирана алатка за да направите многу
на административните функции на mySQL. href="http://www.freebsdforums.org"
>Форуми за FreeBSD

Објавено од во понеделник, 25 февруари 2002 година, @ 6:03 часот

[Избриши] [Уреди]

Потврдено на MySQL 3.23.36 на Red Hat Linux 7.1:
Забележете дека ако пишувате
користете a_c;
доделување изберете на * до ;
ќе ви биде овозможен пристап до било кој
база на податоци се совпаѓа со „a_c“ каде што долната црта е a
џокер. (Ретко проблем, претпоставувам).
Поправете со
ажурирање mysql.db сет db="a\_c" каде што db="a_c";

Испратено од jan behrens во вторник, 9 јули 2002 година, @ 1:31 часот

[Избриши] [Уреди]

гореспоменатата бубачка од DAN ELIN во x.x.41 е
очигледно сè уште важи во x.x.51, не можам да се логирам на a
база на податоци по ДОДЕЛУВАЊЕ на привилегии и дадена а
лозинка за нов корисник (да, испуштив
привилегии)............. е можен само root пристап

Испратено од Ден Егли во четврток, 4 април 2002 година, @ 20:33

[Избриши] [Уреди]

Се чини дека има грешка во 3.23.41 со помош на Grant.
Само root може дури и да пристапи до базата на податоци mysql
по користењето на Грант за доделување привилегии за што и да е
база на податоци/табела/колона/итн.. секогаш добивате
дозволата е одбиена, без разлика.

Објавено од Ларс Аронсон во сабота, 8 јуни 2002 година, @ 11:16 часот

["%". Кога се обидувам да ги избришам, ми е кажано одредена база на податоци, но нема глобални привилегии КРЕИРАЈ ПРИВРЕМЕНА ТАБЕЛА привилегија на таа база на податоци се негира. Мора да дадете глобална CREATE __и__ глобална КРЕИРАЈТЕ ПРИВРЕМЕНИ ТАБЕЛИ на корисникот. IOW: ГРАНТ КРЕИРАЈ, КРЕИРАЈ ПРИВРЕМЕНИ ТАБИ НА *.* ДО ; Непотребно е да се каже дека ова сериозно влијае на безбедноста. Објавено од во недела, 25 август 2002 година, @ 9:17 часот [Избриши] [Уреди] Привремените датотеки се одлична идеја, но дури и со Креирајте и креирајте права за привремена датотека во корисничка (глобални права) датотека сè уште не работи. Се чини дека ова е лошо дизајнирано. Објавено од Бред Булгер во понеделник, 2 септември 2002 година, @ 04:09 часот [Избриши] [Уреди] Треба да се напомене дека само СО ОПЦИЈА ЗА ГРАНТ му овозможува на корисникот да пренесува привилегии на корисници кои веќе постои. Автоматско создавање на корисникот рекорди не еаплицирај - добиваш грешка велејќи што го прави корисникот со привилегија GRANT OPTION немаат пристап до базата на податоци „mysql“. Ова е веројатно е добра работа, но треба да се документира. Објавено од Мајкл Бабкок во петок, 8 ноември 2002 година, @ 13:00 [Избриши] [Уреди] Покажи ГОДИШЕН СТАТУС бара привилегии за PROCESS. Други такви непарни комбинации треба да се документираат. Објавено од Ди Кинтауди во четврток, 21 ноември 2002 година, @ 12:42 часот [Избриши] [Уреди] Добро, добив прашање и проблем со Mysql и лозинки :). Се обидов да користам неколку од опциите а повеќето од нив не работеле. Сепак еден soloution работеше и го тестирав двапати и тоа беше солидна. Секако дека го изгубив малото парче хартија I го напишав и не можам да го најдам ова решение каде било, како да го немало или можеби јас го замисли. Решението што работеше за мене, пред да го изгубам малото ливче, го запишав оди нешто вака..... Вметнете вокориснички корен Лозинка „моја лозинка“ и потоа нешто со "Y", "Y", "Y", (околу десетина или 15 пати или така) Сепак, никаде не можам да го најдам ова решение некој да ми помогне овде? Мислам дека би било многу убаво само да го стават ова низ нивната документација наместо да се обидуваат да Скриј го. Мислам дека ова ќе реши многу проблеми. Само стави лозинка = "Y", "Y", "Y", како тие се срамат од тоа или нешто. Објавено од AJIT DIXIT во понеделник, 25 ноември 2002 година, @ 6:56 часот [Избриши] [Уреди] Кога работам на ажурирање со повеќе табели со root корисник работи добро Кога работам со не-root корисник добивам грешка Sql: ажурирање Stockists, области поставени a_nm = aname каде што acd = површина

Во ова поглавје, ќе научите како да работите со привилегии. Како што беше дискутирано во Поглавје 2, SQL обично се користи во средини кои бараат корисничко препознавање и разлика помеѓу различни корисници на системи. Општо земено, администраторите на базата сами создаваат корисници и им даваат привилегии. Од друга страна, корисниците кои самите креираат табели имаат право да управуваат со овие табели. Привилегиите се тие што одредуваат дали одреден корисник може да изврши дадена команда. Постојат неколку видови на привилегии кои одговараат на неколку видови операции. Привилегиите се доделуваат и укинуваат со користење на две SQL команди: - GRANT и REVOKE. Ова поглавје ќе ви покаже како се користат овие команди.

КОРИСНИЦИ

Секој корисник во SQL околина има посебно име или број за идентификација. Терминологијата е различна насекаде, но ние избравме (следејќи го ANSI) да се однесуваме на неа или на бројот како Идентификатор за пристап (ID). Командата испратена до базата на податоци е поврзана со одреден корисник; или на друг начин, посебен идентификатор за пристап. Што се однесува до базата на податоци на SQL, ID на дозволата е корисничкото име, а SQL може да го користи специјалниот клучен збор КОРИСНИК, кој се однесува на ИД за пристап поврзан со тековната команда. Командата се толкува и е дозволена (или одбиена) врз основа на информации поврзани со ИД за пристап на корисникот што ја издава командата.

РЕГИСТРАЦИЈА

Во системи со бројни корисници, постои некаква процедура за најава која корисникот мора да ја заврши за да добие пристап до компјутерскиот систем. Оваа постапка одредува кој ID на пристап ќе биде поврзан со тековниот корисник. Вообичаено, секое лице што ја користи базата на податоци мора да има сопствен ID за пристап и по регистрацијата станува валиден корисник. Меѓутоа, често корисниците со многу задачи може да се регистрираат под различни идентификатори за пристап, или, обратно, еден идентификатор за пристап може да се користи од неколку корисници. Од SQL перспектива нема разлика помеѓу овие два случаи; го третира корисникот едноставно како негов ID за пристап. Базата на податоци SQL може да користи сопствена процедура за најава или може да дозволи друга програма, како на пр операционен систем(главната програма што работи на вашиот компјутер), обработете ја датотеката за регистрација и добијте ID за пристап од оваа програма. На еден или друг начин, SQL ќе има ID за пристап за да се поврзе со вашите дејства, а клучниот збор КОРИСНИК ќе биде релевантен за вас.

ОБЕЗБЕДУВАЊЕ ПРИВИЛЕГИ

Секој корисник во базата на податоци SQL има збир на привилегии. Ова е она што му е дозволено да го прави корисникот (можеби тоа е лог датотека, која може да се смета за минимална привилегија). Овие привилегии може да се променат со текот на времето - нови се додаваат, старите се отстрануваат. Некои од овие привилегии се дефинирани во ANSI SQL, но има и дополнителни привилегии кои исто така се потребни. Привилегиите на SQL како што е дефинирано од ANSI не се доволни во повеќето ситуации од реалниот живот. Од друга страна, типовите на привилегии кои се потребни може да варираат во зависност од типот на системот што го користите - за кој ANSI не дава препораки. Привилегиите кои не се дел од стандардот SQL може да користат синтакса што е слична и не е целосно конзистентна со стандардот.

СТАНДАРДНИ ПРИВИЛЕГИ

Привилегиите на SQL дефинирани од ANSI се привилегии за објект. Ова значи дека корисникот има привилегија да изврши дадена команда само на одреден објект во базата на податоци. Очигледно, привилегиите мора да прават разлика помеѓу овие објекти, но системот за привилегии базиран исклучиво на привилегиите на објектот не може да одговори на сè што му треба на SQL, како што ќе видиме подоцна во ова поглавје. Привилегиите на објектот се поврзани и со корисници и со табели. Односно, привилегијата се дава на одреден корисник во одредена табела, или основна табела или приказ. Мора да запомните дека корисникот кој ја создал табелата (од кој било вид) е сопственик на оваа табела.

Ова значи дека корисникот ги има сите привилегии во оваа табела и може да ги пренесе привилегиите на други корисници во оваа табела. Привилегии што може да му се доделат на корисник:

ИЗБЕРИ Корисник со оваа привилегија може да извршува прашања на табелата.

INSERT Корисникот со оваа привилегија може да издаде команда INSERT на табела.

АЖУРИРАЈ Корисникот со оваа привилегија може да издаде команда UPDATE на табела. Можете да ја ограничите оваа привилегија на одредени колони од табелата.

БРИШИ Корисникот со оваа привилегија може да издаде команда DELETE на табела.

РЕФЕРЕНЦИ Корисникот со оваа привилегија може да дефинира странски клуч кој користи една или повеќе колони од оваа табела како матичен клуч. Можете да ја ограничите оваа привилегија на одредени колони. (Видете Поглавје 19 за детали во врска со странскиот клуч и родителскиот клуч.)

Дополнително, ќе наидете на нестандардни привилегии за објект, како што е INDEX, кој дава право да креира индекс на табела, SYNONYM, кој дава право да креира синоним за објект, што ќе биде објаснето во Поглавје 23. и ALTER, што дава право да се изврши командата ALTER TABLE на табела. SQL моторот ги доделува овие привилегии на корисниците користејќи ја командата GRANT.

ГРАНТ ТИМ

Да претпоставиме дека корисникот Дајан има табела со клиенти и сака да му дозволи на корисникот Адријан да ја побара. Потоа Дајан треба да ја внесе следнава команда:

ГРАНТ ИНСЕРТ ЗА продавачи ДА Дајан;

Сега Адријан може да извршува прашања во однос на табелата со клиенти. Без други привилегии, тој може да избира само вредности; но не може да изврши никакво дејство што би влијаело на вредностите во табелата Клиенти (вклучувајќи ја и употребата на табелата Клиенти како матична табела на странскиот клуч, што ги ограничува промените што можат да се направат на вредноста во табелата Клиенти).

Кога SQL добива команда GRANT, ги проверува привилегиите на корисникот што ја издава командата за да утврди дали командата GRANT е валидна. Адријан не може сам да ја издаде оваа команда. Исто така, не може да даде дозвола SELECT на друг корисник: табелата сè уште припаѓа на Diane (подоцна ќе покажеме како Дајан може да му даде дозвола на Adrian SELECT на други корисници).

Синтаксата е иста како и за доделување други привилегии. Ако Адријан е сопственик на табелата Продавачи, тогаш тој може да дозволи Дајан да внесува редови во неа користејќи ја следната клаузула

ГРАНТ ИНСЕРТ ЗА продавачи ДА Дајан; Дајан сега има право да постави нов продавач во табелата.

ГРУПИ НА ПРИВИЛЕГИ, КОРИСНИЧКИ ГРУПИ

Не треба да се ограничувате на доделување на една привилегија на индивидуален корисник со командата GRANT. Списоците на привилегии или корисници разделени со запирки се сосема прифатливи. Стивен може да обезбеди и SELECT и INSERT во табелата Нарачка за Адријан

ГРАНТ СЕЛЕКТ, ВНЕСЕТЕ НА НАРАЧКИ НА Адријан; или за Адријан и за Дајан ГРАНТ СЕЛЕКТ, ВНЕСЕТЕ НА НАРАЧКИ ДО Адријан, Дајан;

Кога привилегиите и корисниците се наведени на овој начин, целата листа на привилегии им се доделува на сите наведени корисници. Во строгата интерпретација на ANSI, не можете да доделувате привилегии на многу табели одеднаш со една команда, но некои имплементации може да го релаксираат ова ограничување со тоа што ќе ви дозволат да наведете повеќе табели, одделени со запирки, така што целата листа на привилегии може да биде доделена за сите одредени табели..

ОГРАНИЧУВАЊЕ НА ПРИВИЛЕГИИТЕ НА ПОСЕБНИ КОЛОНИ

Сите привилегии на објектот ја користат истата синтакса, освен командите UPDATE и REGERNCES, за кои не се потребни имиња на колони. Привилегијата UPDATE може да се додели како и другите привилегии:

ГРАНТ АЖУРИРАЊЕ ЗА продавачите НА Дајан;

Оваа команда ќе и овозможи на Дајан да ги промени вредностите во која било или сите колони од табелата Добавувачи. Меѓутоа, ако Адријан сака да ја ограничи Дајан да менува, на пример, провизии, може да влезе

ГРАНТ АЖУРИРАЊЕ (comm) ЗА продавачите на Дајан;

Со други зборови, едноставно мора да ја специфицира специфичната колона на која треба да се примени привилегијата UPDATE, во загради по името на табелата. Имињата на повеќе колони од табелата може да се наведат по кој било редослед, разделени со запирки:

ГРАНТ АЖУРИРАЊЕ (град, комуникација) ЗА продавачите ДО Дајан;

РЕФЕРЕНЦИ го следат истото правило. Кога ќе ја доделите привилегијата РЕФЕРЕНЦИ на друг корисник, тој ќе може да креира странски клучеви што ги повикуваат колоните во вашата табела како родителски клучеви. Како АЖУРИРАЊЕ, привилегијата РЕФЕРЕНЦИ може да се наведе како листа од една или повеќе колони за кои таа привилегија е ограничена. На пример, Дајан може да му даде право на Стивен да ја користи табелата за клиенти како табела со матични клучеви со следнава команда:

ГРАНТИРАЈТЕ РЕФЕРЕНЦИ (cname, cnum) ЗА клиентите НА Стефан; Оваа команда му дава право на Стивен да ги користи колоните cnum и cname како родителски клучеви на сите странски клучеви во неговите табели. Стивен може да контролира како се прави тоа. Може да дефинира (cname, cnum) или, во нашиот случај, (cnum, cname), како родителски клуч со две колони што се совпаѓа со странски клуч со две колони во една од неговите сопствени табели. Или може да создаде посебни странски клучеви за да се однесуваат на родот поединечно, со што се осигурува дека Дајан има доделен родителски клуч (види Поглавје 19).

Без ограничувања за броевите на странските клучеви, тој мора да се заснова на овие матични клучеви и мора да се дозволи родителските клучеви на различни странски клучеви да се преклопуваат.

Како и со привилегијата UPDATE, можете да исклучите листа на колони и на тој начин да дозволите сите колони да се користат како матични клучеви. Адријан може да и даде право на Дајан да го направи тоа со следнава команда:

ГРАНТИРАЈТЕ РЕФЕРЕНЦИ ЗА продавачи НА Дајан;

Секако, привилегијата ќе може да се користи само на колони што ги имаат ограничувањата што ги бараат родителските клучеви.

КОРИСТЕЊЕ НА СИТЕ И ЈАВНИ АРГУМЕНТИ

SQL поддржува два аргументи на командата GRANT кои имаат посебно значење: СИТЕ ПРИВИЛЕГИ, или едноставно СИТЕ и ЈАВНИ. СИТЕ се користи наместо имињата на привилегиите во командата GRANT за доделување на сите привилегии во табела. На пример, Дајан може да му го даде на Стивен целиот сет на привилегии во табелата Клиенти со следнава команда:

ГРАНТИРАЈТЕ РЕФЕРЕНЦИ ЗА продавачи НА Дајан;

(Привилегиите за Ажурирање и РЕФЕРЕНЦИ природно важат за сите колони.) Еве уште еден начин да се каже истото:

ГРАНТИРАЈ СИТЕ ЗА клиентите НА Стефан;

PUBLIC е повеќе како тип на аргументи за сите, отколку како корисничка привилегија. Кога давате привилегии за објавување, сите корисници автоматски ги добиваат. Најчесто, ова се користи за привилегијата SELECT на одредени основни табели или прикази што сакате да ги направите достапни за секој корисник. За да му дозволите на секој корисник да ја види табелата за нарачки, на пример, можете да го внесете следново:

ГРАНТ СЕЛЕКТ ПО НАРАЧКИ ДО ЈАВНОСТА;

Се разбира, можете да дадете некоја или сите привилегии на општеството, но тоа веројатно не е препорачливо. Сите привилегии освен SELECT му дозволуваат на корисникот да ја промени (или, во случај на РЕФЕРЕНЦИ, да ја ограничи) содржината на табелата. Дозволувањето на сите корисници да ја менуваат содржината на вашите табели ќе предизвика проблем.

Дури и ако имате мала компанија и сите ваши сегашни корисници се способни да извршуваат наредби за модификација на дадена табела, би било подобро да се доделуваат привилегии на секој корисник поединечно отколку да се доделуваат исти привилегии на секого. PUBLIC не е ограничена само на пренесување на тековните корисници. Било кој Нов корисникдодадена на вашиот систем автоматски ќе ги добие сите привилегии што претходно им беа доделени на секого, па ако сакате да го ограничите пристапот до табелата на секого, сега или во иднина, најдобро е да давате привилегии различни од SELECT на поединечни корисници.

ДАВАЊЕ ПРИВИЛЕГИ КОРИСТЕЊЕ СО ОПЦИЈА ЗА ГРАНТ

Понекогаш, создавачот на табела сака другите корисници да можат да добијат привилегии на неговата маса. Ова обично се прави во системи каде што еден или повеќе луѓе создаваат неколку (или сите) од базните табели во базата на податоци и потоа ја делегираат одговорноста за нив на оние кои всушност ќе работат со нив. SQL ви овозможува да го направите ова користејќи ја клаузулата WITH GRANT OPTION. Ако Дајан сакаше Адријан да може да ја додели привилегијата SELECT на табелата Клиенти на други корисници, таа би му ја доделила привилегијата SELECT користејќи ја клаузулата WITH GRANT OPTION:

ГРАНТ ИЗБИРАЊЕ НА клиентите НА Адријан СО ОПЦИЈА ЗА ГРАНТ; Адријан потоа го стекна правото да ја пренесе привилегијата SELECT на трети лица; може да ја издаде командата GRANT SELECT ON Diane.Customers TO Stephen; или дури и GRANT SELECT ON Diane.Customers TO Stephen СО ГРАНТ ОПЦИЈА; Корисникот со ГРАНТ ОПЦИЈА за одредена привилегија на дадена табела може, пак, да ја даде таа привилегија на истата табела, со или без ОПЦИЈА ЗА ГРАНТ, на кој било друг корисник. Ова не ја менува сопственоста на самата табела; како и досега, табелата му припаѓа на нејзиниот креатор. (Затоа, доделените корисници мора да стават префикс на ИД за пристап на сопственикот кога се повикуваат на овие табели. Следното поглавје ќе ви го прикаже овој метод.) Корисникот што ја користи ОПЦИЈАТА ГРАНТ за сите привилегии за дадена табела ќе има целосна овластување во таа табела.

ПОНИШТУВАЊЕ НА ПРИВИЛЕГИИТЕ

Исто како што ANSI ја обезбедува командата CREATE TABLE за креирање табела, наместо командата DROP TABLE за да се ослободи од неа, командата GRANT ви овозможува да давате привилегии на корисниците без да обезбедите начин да ги вратите назад. Потребата за отстранување на привилегиите се сведува на командата REVOKE, која всушност е стандардна алатка со прилично јасна форма на внесување. Синтаксата на командата REVOKE е слична на GRANT, но има спротивно значење. За да ја отстраните привилегијата INSERT за Adrian во табелата Order, можете да внесете

ПОВЛЕКУВАЈ ИНСЕРТ ЗА нарачки ОД Адријан;

Користењето списоци со привилегии и корисници е дозволено овде како и кај GRANT, па можете да ја внесете следнава команда:

ПОВЛЕКУВАЈТЕ ВНЕСЕНИ, ИЗБРИШЕТЕ НА клиентите ОД Адријан, Стивен; Сепак, тука има одредена нејасност. Кој има право да ги одземе привилегиите? Кога корисник со право да пренесува привилегии на други го губи тоа право? Дали ќе ги загубат и корисниците на кои им ги додели овие привилегии? Бидејќи ова не е стандардна карактеристика, нема авторитативни одговори на овие прашања, но најчестиот пристап е овој: * Привилегиите се одземаат од корисникот кој ги дал, а отповикувањето ќе каскадира, односно автоматски ќе се шири на сите корисници кои ја добиле привилегијата од него .

КОРИСТЕЊЕ НА ПОГЛЕДИТЕ ЗА ФИЛТРИРАЊЕ НА ПРИВИЛЕГИТЕ

Можете да ги направите дејствата за привилегии попрецизни со користење на прегледи. Секогаш кога ќе му дадете привилегија на основната табела на корисник, таа автоматски се шири во сите редови и, кога се користат можните исклучоци за Ажурирање и РЕФЕРЕНЦИ, во сите колони од табелата. Со создавање на приказ кој упатува на основната табела и потоа ја пренесува привилегијата на приказот наместо на табелата, можете да ги ограничите тие привилегии на кој било израз во барањето содржано во приказот. Ова во голема мера ги подобрува основните можности на командата GRANT.

КОЈ МОЖЕ ДА ПОДНЕСУВА?

За да креирате приказ, мора да имате привилегија SELECT на сите табели што ги повикувате во приказот. Ако приказот може да се менува, сите привилегии за Вметнување, Ажурирање и БРИШИ што ги имате на основната табела автоматски ќе се префрлат на приказот. Ако ви недостасуваат привилегии за модификација на основните табели, нема да можете да ги имате на прегледите што ги создавате, дури и ако самите тие прикази се модифицирани. Бидејќи странските клучеви не се користат во прегледите, привилегијата РЕФЕРЕНЦИ никогаш не се користи при креирање прикази. Сите овие ограничувања се дефинирани од ANSI. Може да се овозможат и нестандардни системски привилегии (дискутирани подоцна во ова поглавје). Во следните делови, ќе претпоставиме дека креаторите на ставовите што ги дискутираме имаат приватни или соодветни привилегии на сите основни табели.

ОГРАНИЧУВАЊЕ НА ИЗБОРНА ПРИВИЛЕГИЈА НА СЕКТИВНИ КОЛОНИ

Да речеме дека сакате да му дадете на корисникот Клер можност да ги гледа само колоните snum и sname од табелата за продажба. Можете да го направите ова со ставање на имињата на овие колони во приказот

КРЕИРАЈ ПОГЛЕД Clairesview КАКО ИЗБЕРЕН snum, sname ОД продавачи; и дајте ѝ ја на Клер привилегијата SELECT на приказот наместо на самата табела за продавачи: ГРАНТ ИЗБЕРЕ На Clairesview на Клер; Можете да креирате привилегии специјално за колони, како да користите други привилегии, но за командата INSERT ова ќе ги вметне стандардните вредности, а за командата DELETE, ограничувањето на колоната нема да има ефект. Привилегиите РЕФЕРЕНЦИ и АЖУРИРАЊЕ, се разбира, можат да ги направат колоните специфични без прибегнување кон приказ.

ОГРАНИЧУВАЊЕ НА ПРИВИЛЕГИИТЕ ЗА ПОСЕБНИ НИЗИВообичаено, покорисен начин за филтрирање на привилегии со прегледи е да се користи приказот за привилегијата да се применува само на одредени редови. Ова го правите природно со користење на предикат на приказот што ќе определи кои редови се вклучени. За да му ја дадете на корисникот Адријан привилегијата АЖУРИРАЊЕ на табелата Клиенти за сите клиенти лоцирани во Лондон, можете да креирате приказ како овој:

КРЕИРАЈ ПОГЛЕД Londoncust КАКО ИЗБРАН * ОД клиенти КАДЕ град = „Лондон“ СО ОПЦИЈА ЗА ПРОВЕРУВАЊЕ; Потоа мора да му ја дадете привилегијата за АЖУРИРАЊЕ на оваа табела на Адријан: ГРАНТ АЖУРИРАЊЕ НА Лондонкаст НА Адријан; Ова е разликата помеѓу привилегијата за одредени редови и привилегијата АЖУРИРАЊЕ за одредени колони, која се однесува на сите колони од табелата Клиенти, но не и на редовите, меѓу кои нема да се земат предвид редовите со род на градот, различна од Лондон. . Клаузулата WITH CHECK OPTION го спречува Адријан да ја промени вредноста на полот на градот на што било друго освен Лондон. ОБЕЗБЕДУВАЊЕ ПРИСТАП САМО ДО ИЗВЕДЕНИТЕ ПОДАТОЦИДруга можност е да им се понуди на корисниците пристап до податоците што се веќе преземени, наместо до вистинските вредности во табелата. Агрегатните функции може да бидат многу погодни при користење на овој метод. Можете да креирате приказ што ги дава броењето, просекот и вкупниот број на нарачки за секој ден од нарачката: СОЗДАДЕТЕ ПОГЛЕД Датумски вкупни податоци КАКО ИЗБЕРЕН датум, COUNT (*), SUM (amt), AVG (amt) FROM Orders GROUP BY odate; Сега на корисникот Дајан му ја давате привилегијата ИЗБИРУВАЊЕ на приказот Датумски суми: ГРАНТ ИЗБЕРЕ НА Датумите на Дајан; КОРИСТЕЊЕ НА ПРЕТСТАВУВАЊАТА КАКО АЛТЕРНАТИВА НА ОГРАНИЧУВАЊАТАЕдна од најновите апликации во серијата, опишана во Поглавје 18, е употребата на погледи со ОПЦИЈА ЗА ПРОВЕРУВАЊЕ како алтернатива на ограничувањата. Да речеме дека сакавте да се уверите дека сите родови вредности на градот во табелата за продавачи се во еден од градовите каде што вашата компанија моментално има канцеларија. Можете да поставите ограничување CHECK директно на градската колона, но може да стане тешко да го промените подоцна ако вашата компанија отвори други одделенија таму, на пример. Алтернативно, можете да креирате приказ што ги исклучува неважечките вредности на градот: СОЗДАДЕТЕ ПОГЛЕДНИ валути КАКО ИЗБРАНИ * ОД продавачи КАДЕ ВО град („Лондон“, „Рим“, „Сан Хозе“, „Берлин“) СО ОПЦИЈА ЗА ПРОВЕРУВАЊЕ; Сега, наместо да им давате на корисниците привилегии за модификација во табелата Трговци, можете да им доделите во приказот Curcities. Предноста на овој пристап е што ако треба да направите промена, можете да го избришете тој приказ, да креирате нов и да им дадете привилегии на корисниците во тој нов приказ, што е полесно од менувањето на ограничувањата. Недостаток е што сопственикот на табелата за продажба мора исто така да го користи овој приказ ако не сака неговите сопствени команди да бидат отфрлени. Од друга страна, овој пристап му овозможува на сопственикот на табелата и на кој било друг да добијат привилегии за модификација на самата табела, наместо на приказот, да прават исклучоци од ограничувањата.

Ова е често пожелно, но не е изводливо ако користите ограничувања на основната табела. За жал, овие исклучоци нема да бидат видливи во приказот. Ако го изберете овој пристап, ќе сакате да создадете втор приказ кој содржи само исклучоци: КРЕИРАЈ ПОГЛЕД Други градови КАКО ИЗБРАНИ * ОД продавачи КАДЕ НЕ ВО градот („Лондон“, „Рим“, „Сан Хозе“, „Берлин“) СО ПРОВЕРКА ОПЦИЈА; Треба да изберете да им дадете на корисниците само привилегијата SELECT на овој приказ за да можат да ги видат исклучените редови, но да не можат да стават неважечки вредности на градот во основната табела. Всушност, корисниците можеа да ги прашаат двата погледи во унија и да ги видат сите редови одеднаш.

ДРУГИ ВИДОВИ ПРИВИЛЕГИИ

Се разбира, сакате да знаете кој има право прв да ја креира табелата. Оваа област на привилегии не е ANSI, но не може да се игнорира. Сите стандардни ANSI привилегии се изведени од оваа привилегија; привилегии на креаторите на табели кои можат да ги пренесат привилегиите на објектот. Ако сите ваши корисници креираат базни табели во системот со различни големинитоа ќе доведе до вишок во нив и до неефикасност на системот. Други прашања исто така привлекуваат внимание:

Кој има право да менува, брише или ограничува табели?

Дали правата за креирање базни табели треба да се разликуваат од правата за создавање прегледи?

Дали треба да постои суперкорисник - корисник кој е одговорен за одржување на базата на податоци и затоа ги има повеќето, или сите, привилегии кои не се доделуваат поединечно?

Сè додека ANSI не се вклучи и SQL не се користи во различни средини, не можеме да дадеме дефинитивен одговор на овие прашања. Предлагаме овде да разгледаме дел од најопштите заклучоци.

Привилегиите кои не се дефинирани во смисла на специјални објекти на податоци се нарекуваат системски привилегии или права на базата на податоци. На основно ниво, тие најверојатно ќе го вклучуваат правото да се креираат податочни објекти, веројатно различни од базните табели (обично креирани од неколку корисници) и погледите (обично креирани од мнозинството корисници). Системските привилегии за креирање погледи треба да бидат дополнување, а не наместо, привилегиите на објектот што ANSI ги бара од креаторите на погледи (опишани претходно во ова поглавје). Дополнително, во систем од која било големина секогаш има некои типови на суперкорисници - корисници кои автоматски ги имаат повеќето или сите привилегии - и кои можат да го пренесат својот статус на суперкорисник на некој друг преку привилегија или група на привилегии. Администратор на база на податоци, или DBA, е терминот што најчесто се користи за таков суперкорисник и привилегиите што ги има.

ТИПИЧНИ ПРИВИЛЕГИ НА СИСТЕМ

Во општиот пристап, постојат три основни системски привилегии: - ПОВРЗИ, - РЕСУРСИ и - DBA (Администратор на база на податоци). Поедноставно кажано, CONNECT може да се каже дека се состои од право на регистрација и право на создавање прикази и синоними (види Поглавје 23) доколку се препуштат привилегиите на објектот. РЕСУРС се состои од правото да се креираат базни табели. DBA е суперкорисничка привилегија која му дава на корисникот висок авторитет во базата на податоци. Еден или повеќе корисници со функционалност на администратор на базата на податоци може да ја имаат оваа привилегија. Некои системи имаат и специјален корисник, понекогаш наречен SYSADM или SYS (Системски администратор на бази на податоци), кој има највисока власт; тоа е посебно за нив, а не само корисник со посебна привилегија за DBA. Всушност, само на едно лице му е дозволено да се регистрира со името SYSADM, што е нивниот ID за пристап. Разликата е прилично суптилна и функционира различно во различни системи. За наши цели, ќе се повикаме на високо привилегиран корисник кој развива и управува со база на податоци со DBA привилегии, разбирајќи дека всушност овие привилегии се истата привилегија. Командата GRANT, во изменета форма, може да се користи со привилегии за објект, како и со системски привилегии. За почеток, преносот на правата може да се направи со помош на DBA. На пример, DBA може да му даде привилегија за креирање табели на Родригез на следниов начин: ГРАНТИРАЈ РЕСУРСИ НА Родригез;

КРЕИРАЈ И ИЗБРИШИ КОРИСНИЦИ

Природно се поставува прашањето, од каде потекнува корисникот по име Родригез? Како да се одреди неговиот ID за дозвола? Во повеќето имплементации, DBA го креира корисникот со тоа што автоматски му ја доделува привилегијата CONNECT. Во овој случај, обично се додава клаузула ИДЕНТИФИРАНО СО за да се наведе лозинката. (Ако не, оперативниот систем мора да одреди дали можете да се најавите во базата на податоци со дадениот ID на пристап.) DBA може, на пример, да издаде GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon; кој ќе создаде корисник по име Телониус, ќе му даде право да се регистрира и ќе му ја додели лозинката Redwagon, се во една реченица. Бидејќи Thelonious е веќе автентификуван корисник, тој или DBA може да ја користат истата команда за да ја сменат лозинката на Redwagon. Иако ова е погодно, сè уште има ограничувања во овој пристап. Ова е неможноста да се има корисник кој не може да се регистрира, барем привремено. Ако сакате да спречите логирање на корисник, мора да ја користите привилегијата CONNECT на REVOKE, што го „отстранува“ тој корисник. Некои имплементации ви дозволуваат да креирате и бришете корисници, без оглед на нивните привилегии за најава. Кога ќе му ја дадете привилегијата CONNECT на корисник, вие го создавате тој корисник. Покрај тоа, за да го направите тоа сами, мора да имате привилегија на DBA. Ако овој корисник создава базни табели (не само прегледи), мора да му се додели и привилегијата РЕСУРС. Но, ова веднаш предизвикува друг проблем. Ако се обидете да ја отстраните привилегијата CONNECT на корисник кој има табели создадени од него, командата ќе биде отфрлена бидејќи ќе ја остави табелата без сопственик, што не е дозволено. Прво мора да ги исфрлите сите табели создадени од овој корисник пред да ја отстраните неговата привилегија CONNECT. Ако овие табели не се празни, тогаш веројатно ќе сакате да ги пренесете нивните податоци на други табели користејќи ја командата INSERT, која користи барање. Не треба посебно да ја отстранувате привилегијата РЕСУРС; Доволно е да се избрише CONNECT за да се избрише корисникот. Иако горенаведеното е прилично стандарден пристап кон системските привилегии, исто така има значителни ограничувања. Се појавија алтернативни пристапи кои се поконкретно дефинирани и попрецизно ги контролираат привилегиите на системот.

Овие заклучоци нè одведуваат малку подалеку од SQL стандардот како што е моментално дефиниран и, во некои имплементации, може целосно да го надминат стандардот SQL. Овие работи веројатно нема да ве засегаат премногу, освен ако не сте DBA или корисник високо ниво. Редовните корисници едноставно треба да се запознаат со привилегиите на системот во принцип, консултирајќи се со нивната документација само во случај на специјални пораки.

РЕЗИМЕ

Привилегиите ви даваат можност да ја видите SQL од нова перспектива кога SQL врши дејства преку специјални корисници на специјален систем на база на податоци. Самата команда GRANT е прилично едноставна: со нејзина помош давате одредени привилегии на некој објект на еден или повеќе корисници. Ако на корисник му ја доделите привилегијата WITH GRANT OPTION, тој корисник за возврат може да ја даде таа привилегија на други. Сега ги разбирате советите за користење на привилегии за прегледи - за подобрување на привилегиите во основните табели или како алтернатива на ограничувањата - и некои од предностите и недостатоците на овој пристап. Системските привилегии кои се потребни, но не во опсегот на стандардот SQL се дискутирани во нивната најопшта форма и така ќе ги научите преку пракса. Поглавје 23 ќе ја продолжи дискусијата за заклучоците во SQL, како што се зачувување или обновување на промените, создавање ваши имиња за табели во сопственост на други луѓе и разбирање што се случува кога различни корисници се обидуваат да пристапат до истиот објект во исто време.

РАБОТА СО SQL

1. Дајте му на Џенет право да го промени рејтингот на клиентот.

2. Дајте му на Стефан правото да им даде право на други корисници да поставуваат прашања во табелата за нарачки.

3. Отстранете ја привилегијата INSERT во табелата Добавувачи од Claire и од сите корисници на кои им беше доделена.

4. Дајте му на Џери право да ја вметне или менува табелата со клиенти додека ја задржува неговата способност да оценува вредности во опсег од 100 до 500.

5. Дозволете ѝ на Џенет да ја бара табелата со клиенти, но спречете ја да ги намалува рејтинзите во истата табела со клиенти.

Платформата SQL Server ја користи изјавата REVOKE како начин за отповикување на поставките за дозвола доделени на даден корисник. Оваа точка е важна затоа што SQL Server поддржува дополнителна изјава DENY која експлицитно негира пристап на корисникот до одреден ресурс. Во SQL Server, изјавата REVOKE може да се користи за отповикување на привилегиите доделени на корисник користејќи ја изјавата GRANT. Ако сакате експлицитно да му одбиете одредена привилегија на корисникот, треба да ја користите изјавата DENY.

Платформата SQL Server не ги поддржува клаузулите ANSI HIERARCHY OPTION и ADMIN OPTION. Иако клаузулата ADMIN OPTION не е поддржана, верзијата на SQL Server на командата REVOKE има две административни привилегии (CREATE и BACKUP). Синтаксата на инструкциите е како што следува.

РЕВОКИРАЈ ([објект_привилегија] [, ...] | [системска_привилегија]) [(колона [, ...])]]| (ДО | ОД) (име на примачот [, …] | улога [, …] | ЈАВНО | ГОСТИН) ]

ГРАНТ ОПЦИЈА ЗА

Корисникот е лишен од правото да доделува конкретни привилегии на други корисници.

објект привилегија

Правата за пристап до различни инструкции, кои може да се комбинираат по кој било редослед, се отповикани.

СИТЕ

Сите привилегии доделени во моменталноодредени корисници и/или за одредени објекти на базата на податоци. Овој предлог е обесхрабрен бидејќи промовира нејасност во програмирањето.

(ИЗБЕРЕТЕ | ВНЕСЕТЕ ИЗБРИШЕЊЕ АЖУРИРАЊЕ)

На наведениот корисник му е одбиена одредената привилегија за пристап на наведениот објект (на пример, табела или приказ). За да ги отповикате привилегиите на ниво на колона, користете список со колони затворени во загради.

РЕФЕРЕНЦИ

Правото да се креираат и бришат ограничувања за странски клучеви кои упатуваат на објект на базата на податоци како матичен објект е отповикано.

Правото на корисникот да креира или брише правило во табела или приказ е отповикано.

Правото да се изврши складирана процедура, функција дефинирана од корисникот или продолжена складирана процедура е одземено.

системска привилегија

Правото на извршување на следните изјави е одземено: КРЕИРАЈ БАЗА НА ПОДАТОЦИ, КРЕИРАЈ ПОДАТОЦИ, КРЕИРАЈ ПОДАТОЦИ, КРЕИРАЈ ФУНКЦИЈА, КРЕИРАЈ ПОСТАПКА, КРЕИРАЈ ПРАВИЛО, КРЕИРАЈ ТАБЕЛА, КРЕИРАЈ ПОГЛЕД, РЕЗЕРВНА БАЗА НА ПОДАТОЦИ и РЕЗЕРВЕН ДНЕВНИК.

ВКЛУЧЕНО [објект] [(колона [, ...])]

Правото на пристап на корисникот до наведениот објект е одземено. Ако објектот е табела или приказ, можете да ги отповикате привилегиите за пристап на поединечни колони. Можете да ги отповикате привилегиите SELECT, INSERT, UPDATE, DELETE и REFERENCES на табела или приказ. На колоните за табела или приказ, можете само да ги отповикате привилегиите SELECT и UPDATE. Може да ги отповикате привилегиите EXECUTE во складирана процедура, функција дефинирана од корисникот или продолжена зачувана процедура.

[ДО | FROM] име на примач | улога | ЈАВНИ | ГОСТИН

Ги одредува корисниците или улогите што ја губат наведената привилегија. Можете да го користите клучниот збор PUBLIC за да ги отповикате привилегиите доделени на улогата PUBLIC (која ги вклучува сите корисници). Можете да наведете повеќе примачи, одвојувајќи ги нивните имиња со запирки. Поддржано и во SQL Server Сметка GUEST, кој го користат сите корисници кои немаат сопствен запис во базата на податоци.

Привилегиите на корисниците кои ги добиле своите права преку клаузулата СО ГРАНТ ОПЦИЈА се отстранети. Оваа клаузула е потребна кога се користи клаузулата ГРАНТ ОПЦИЈА ЗА.

AS (група_име на улога)

Наведени се правата под кои се укинува привилегијата. Во некои случаи, на корисникот може привремено да му требаат правата на одредена група за да ги отфрли наведените привилегии. Во овој случај, можете да ја користите клаузулата AS за да ги добиете таквите права.

Двете форми на изјавата REVOKE, REVOKE привилегијата на објектот и REVOKE system_privilege, меѓусебно се исклучуваат. Не обидувајте се да ги направите двете операции во една изјава. Клучната синтаксичка разлика помеѓу двете е тоа што не треба да ја користите клаузулата ON кога ги отстранувате системските привилегии. На пример, за да отстраните системска привилегија, можете да ја користите следнава команда.

РЕВОКИ, КРЕИРАЈ БАЗА НА ПОДАТОЦИ, РЕЗЕРВНА БАЗА НА ПОДАТОЦИ ОД dylan, katie

Ако привилегиите му биле доделени на корисник што ја користи клаузулата СО ГРАНТ ОПЦИЈА, тогаш овие привилегии треба да се отповикаат со истовремена употреба на две клаузули - СО ГРАНТ ОПЦИЈА и КАСКАДА. На пример:

ОТКАЖИ ОПЦИЈА ЗА ГРАНТ ЗА ИЗБИРА, ВНЕСИ, АЖУРИРА, ИЗБРИШЕ НА наслови ДО уредниците CASCADE GO

Командата REVOKE може да се користи само на тековната база на податоци. Според тоа, стандардните опции ANSI CURRENTJJSER и CURRENTROLE секогаш се имплицитно претпоставени. Изјавата REVOKE се користи и за откажување на сите DENY опции.

Платформата SQL Server, исто така, поддржува дополнителна изјава DENY. Синтаксата на изјавата DENY е идентична со синтаксата на изјавата REVOKE. Меѓутоа, во суштина, тие се разликуваат по тоа што REVOKE ги неутрализира привилегиите на корисникот, додека DENY експлицитно ги забранува. Користете ја изјавата DENY за да одбиете пристап на корисник или улога до привилегија, дури и ако привилегијата е дадена експлицитно или преку доделување улога.

Изјавата REVOKE мора да се користи за отстранување на претходно доделени или DENY привилегии. На пример, корисникот Кели отишол на продолжено породилно отсуство. За тоа време ѝ бил забранет пристапот до масата на вработените. Таа се врати и повторно дозволивме привилегии.

Одбијте ги сите вработени за да отиде Кели

ОТКАЖЕТЕ СИТЕ НА вработените ДА Кели ОДИ

Во овој пример, командата REVOKE не ги отстранува нејзините привилегии, туку ја поништува командата DENY.

Создавањето корисник само по себе не му дава никакви права на корисникот за пристап до објектите на базата на податоци.

Дозволите ги дава командата GRANT. Треба да се запомни дека корисникот што ја издава командата GRANT може да ги пренесе или, ако сакате, да ги делегира на други корисници само оние права што тој самиот ги има.

ГРАНТ поставува права на објекти на базата на податоци на корисници, улоги или други објекти на базата на податоци. Кога се создава објект, само неговиот создавач има права на него и само тој може да дава права на други корисници или објекти.

За да пристапи до табела или приказ, на корисникот или објектот му требаат права SELECT, INSERT, UPDATE, DELETE или REFERENCES. Сите права може да се дадат со опцијата СИТЕ.

За да повикате процедура во апликација, корисникот мора да има права EXECUTE.

Корисниците можат да добијат дозвола за доделување права на други корисници со пренесување на правата според списокот , што е специфицирано со опцијата СО ГРАНТ ОПЦИЈА. Корисникот може да им ги додели на другите само оние права што тој самиот ги има.

Дозволите може да им се дадат на сите корисници со користење на опцијата ЈАВНО наместо списокот со кориснички имиња. Одредувањето на опцијата PUBLIC влијае само на корисниците, а не на објектите на базата на податоци.

Списокот на права е даден во табела. 8.5.

Табела 8.5. Список на права

Правата може да бидат отповикани од корисникот кој ги доделил користејќи ја командата REVOKE. Ако правата се издадени со користење на СИТЕ, тогаш тие можат да се ликвидираат само во режимот СИТЕ;

Синтакса:

ГРАНТ (сите /ПРИВИЛЕГИ] / LJST_ ) ВКЛУЧЕНО (ТАБЕЛА ]

(име на маса/име на преглед)

ДО(