как в БД реализованы права доступа на уровне отдельных записей?

[Axe Ilshat]

помогите чайнику плз.
Предположим есть таблица, куча пользователей. Как реализуется то, что каждый пользователь может редактировать только свои записи в таблице?

Из того что знаю. Можно создать таблицу view на основе базовой таблицы с выборкой и дать соотв. пользователю право ее редактировать.
Но, для меня неясным остается ряд вопросов, как происходит добавление новых записей в базовую таблицу. Они, в таком случае, должны соответствовать критерию выборки. Как это контролируется? И второй вопрос: если пользователей 50-100 чел и таблиц штук 20?

Из того что предполагаю. Можно ли в хранимых процедурах(ХП) менять пользователя, то есть авторизироваться на СКЛ другим пользователем и уже на уровне ХП решать вопрос о провомерности тех или иных действий пользователя?

Подскажите где копать, а там я уж вырулю.

[REM]

Способ решения данной проблемы сильно зависит от конкретной реализации СУБД.

Могу предложить следующий подход: добавить в таблицу колонку с ID юзверя и  модифицировать скрипты так, чтобы они отфильтровывали записи по UserId, в соответствии с действующей системой прав доступа. Если таблиц много, имеет смысл  фильтрацию по UserId выделить в отдельную ХП.

[Sla]

согласен с REM, достаточно проста реализация
второй вариант
можно создать табличку с idзаписи idтабдицы и idюзера
и СУБД какое?

[Alf]

Еще довольно простое решение - использовать вид (view). Это может оказаться проще, чем ХП, поскольку с видом можно работать, как с таблицей, прозрачно для пользователя.

[Sla]

Alf, согласен. Но какие-то действия дли идентификации юзера надо принять

[REM]

Еще довольно простое решение - использовать вид (view). Это может оказаться проще, чем ХП, поскольку с видом можно работать, как с таблицей, прозрачно для пользователя.

Alf, согласен. Но какие-то действия дли идентификации юзера надо принять.

А что мешает совместить эти два подхода? Итоговое решение такое: В каждой таблице иметь колонку UserId, чтобы помнить какой юзверь довабил запись. Обращение к таблице (как чтение, так и запись) вести посредством вьюшки, созданной на основе таблицы. Добавить во вьюшку выражение where, фильтрующее записи в соответствии с системой прав.

Недостаток такого подхода:
1.  При изменении системы прав доступа придётся править сразу все вьюшки. Например такая проблема может возникнуть, если в начале система прав работала так: "каждый пользователь может редактировать только свои записи в таблице", а затем добавили администратора, который может редактировать все записи.
2. Нельзя разграничить права на чтение и редактирование.

[Alf]

В принципе права можно задавать на уровне администрирования базы данных. Хотя допускаю, что не все СУБД это позволяют. Впрочем, при должном старании можно найти и базу, не поддерживающую ХП, при нынешнем изобилии все возможно.

Насчет приведенных недостатков не могу согласиться, гибкость настроек определяется лишь возможностями используемой СУБД. Например, в MS SQL возможно контролировать права доступа не только к таблицам, но и к отдельным полям. Но это уже специфика среды, тут однозначно не скажешь. Чем примитивнее среда, тем больше усилий на безопасность придется потратить программисту, закон сохранения.

[REM]

Насчет приведенных недостатков не могу согласиться, гибкость настроек определяется лишь возможностями используемой СУБД. Например, в MS SQL возможно контролировать права доступа не только к таблицам, но и к отдельным полям. Но это уже специфика среды, тут однозначно не скажешь. Чем примитивнее среда, тем больше усилий на безопасность придется потратить программисту, закон сохранения.

Безусловно, если СУБД позволяет контролировать права доступа к отдельным полям, то о приведённых недостатках не может быть и речи. Я говорил именно о подходе, использующем UserId.

[Alf]

Правильно, я тоже о нем. СУБД позволяет управлять доступом к полям, но не строкам, поэтому для данной задачи это мало что дает. Вид отфильтрует нужные строки, а система безопасности пресечет попытки несанкционированного доступа, если автор приложения что-то прозевает. В совокупности оба приема дадут вполне приемлемый результат.

[Sla]

я сталкивался с такой системой, имя админа было во всех вьюхах и во всех функциях и процедурах.

[REM]

Правильно, я тоже о нем. СУБД позволяет управлять доступом к полям, но не строкам, поэтому для данной задачи это мало что дает.

Нда. Сорри за невнимательность. Просто я перепутал поля со строками

[Axe Ilshat]

1. Я использую MySQL 5.0
2. Да, есть возможность установления доступа к отдельным полям. Но как это поможет? Каждый юзверь должен иметь доступ ко всем полям в базовой таблице.
3. Вы предлагаете контроль на уровне программы клиента. Конечно здорово - гибко и  легко реализуемо, но... Что будет если найдется какой нибудь идиот, который знаком с СУБД и подключится к БД другим клиентом. В консольном доступе ему будет доступно все... Именно в этом и заключается моя проблема.

[Alf]

Нда. Сорри за невнимательность. Просто я перепутал поля со строками

Ничего страшного, задача сводится к уже решенной путем поворота таблицы на 90 градусов

[Axe Ilshat]

1. Предлагаете использовать вид? А в view можно добавлять записи? Я считал что он только для просмотра.
2. Если можно добавлять записи, как учитываются столбцы по которым сделана выборка? Например CREATE VIEW test.v AS SELECT * FROM t WHERE test.c=1;  При вставке новых и измененении существующих строк, что происходит со столбцом test.с? Является ли он столбцом с жестко заданным значением при вставке новых строк и константой при редактировании строк?  А если этот столбец в итоге не входит в результирующий вид?
3. И в силе остается старый вопрос. У меня реально таблиц будет штук 30, может больше. Пользователей около 50-70. Получается придется создать 30х50 view???  Можно конечно и динамически их создавать...

[Axe Ilshat]

Можно конечно и динамически их создавать...

ну это я сморозил. Тогда какой прок от него

[REM]

1. Предлагаете использовать вид? А в view можно добавлять записи? Я считал что он только для просмотра.

Это вопрос не простой. Добавлять записи можно только в редактируемую вьюшку. Что считается редактируемой вьюшкой в  MySQL 5.0 я не знаю, тут надо обратиться к документации.

3. И в силе остается старый вопрос. У меня реально таблиц будет штук 30, может больше. Пользователей около 50-70. Получается придется создать 30х50 view???  Можно конечно и динамически их создавать...

Зачем. Хватит и одной на каждую таблицу. Просто надо отфильтровать строки, на которые данный пользователь не имеет прав.

[REM]

Нда. Сорри за невнимательность. Просто я перепутал поля со строками

Ничего страшного, задача сводится к уже решенной путем поворота таблицы на 90 градусов

[Axe Ilshat]

[Хватит и одной на каждую таблицу

Не понял. Поясните на примере плз. Например таблица
create table test (id int auto_increment, data text, userid int, PRIMARY KEY(id));
Как создать вид, который бы отбирал только те строки таблицы которые соответствуют пользователю с конкретным userid, причем этот вид должен подходить всем пользователям.

В MySQL вид редактируем, оказывается. Нашел все таки. Хелп дубовый.
Только полям по которым выборка осуществлялась и которые входят в вид придется ручками задавать корректные значения при редактировании и вставке строк.
Может ктонибудь подскажет, что происходит, когда это поле не входит в вид.

[Sla]

CREATE VIEW test.v AS SELECT * FROM t WHERE t.c=1 and (t.userid=&user or &user='admin')

[Axe Ilshat]

Все понятно. Спасибо!!!

[Sla]

есть замечание
это хорошо если только на просмотр, и редактирование своих полей,
а теперь предположим что существует группа с правами, например начальник отдела, т.е. видит документы отдела и может их редактировать, или видит но не может редактировать.
Axe Ilshat как ты представляешь это?

[RXL]

Мне с 5.0 работать не приходилось, посему такой вопрос: обращение к VIEW происходит аналогично другим таблицам? Тогда можно ограничения доступа, возможно, настраиваются аналогично - стоит это проверить.

[Axe Ilshat]

Всех с новым годом!  Успехов!

CREATE VIEW test.v AS SELECT * FROM t WHERE t.c=1 and (t.userid=&user or &user='admin')

что то я поспешил. Я подумал что user, это какая то ридонли системная переменная, указывающая имя залогиненного пользователя. Сейчас начал копать дальше и нету такой переменной по крайней мере в мускуле да и в ансишном стандарте.

Во вторых если даже эта переменная есть, то это действительно подойдет только для простой базы данных без иерархии прав. А она у меня как назло есть. Можно конечно и обойтись без неё, но...

Блин, ребят, помогите в самом деле. Сроки летят. Должно же быть что то штатное или методика какая. Ведь любая программа работающая с БД должна решать эту задачу и она давным давно решена. 

З.Ы. Таблицы и виды практически взаимозаменяемы в мускуле.

[Axe Ilshat]

Еще раз хочу повторить, я в БД чайник. Может в факе написано, как решить эту задачу, первой строкой, а вы попросту считаете что я это должен знать.
Задачка то проста. Объясняю для тех кому лень читать ветку с начала.
Есть БД и несколько десятков клиентов в большой организации. Программа-клиент ессно ограничивает права в соответствии с правилами. Но ничто не мешает кому нибудь залогинится телнетом на БД и в обход всех правил там набедокурить.
Структура БД обычна - в таблицах есть строки, которые "пренадлежат" и редактируются только 1-2 пользователями. Остальные строки таблицы этим пользователям можно только просматривать.

Меня удивляет, что для такой распространенной задачи нет ясного решения... 

[RXL]

&user - это не переменная. Сюда надо просто подставить строку с имянем пользователя.

1) создаешь VIEW test.v для определенного пользователя
2) настраиваешь доступ только для него
3) запрещаешь ему изменять поле userid (чтобы не смог свои строки подсунуть кому-то другому)
4) далее, пользователь работает с test.v, как с таблицей

Что тут не выходит?

[Axe Ilshat]

создавать по одному виду таблицы на каждого пользователя?
20 пользователей на 20 таблиц - 400 видов. Вот что смущает. Предпологалось что этой строкой можно будет создать один вид, подходящий для всех пользователей.

[RXL]

VIEW, в данном случае, административный инструмент.

Тогда см. в сторону создания программной прослойки, которая будет контролировать доступ к записям. Ведь, если пользователь будет см определять имя пользователя в запросе, то и контроля не получится - он может подставить все, что угодно.

Я думаю, стоит внимательно почитать мануал.
В mysql-maxdb реализованы процедуры. Проверь, могут ли они обращаться к таблицам, запрещенным для пользователя.

[Axe Ilshat]

Воот спасибо!
я спросил в первом посте

Можно ли в хранимых процедурах(ХП) менять пользователя, то есть авторизироваться на СКЛ другим пользователем и уже на уровне ХП решать вопрос о провомерности тех или иных действий пользователя?

Но так как никто не ответил, даже не стал копать в эту сторону. Спасибо что подтолкнул это проверить. Оказывается БД абсолютно пофигу кто запускает процедуру, главное что бы на запуск было разрешение. Она от рута работает чтоли??? Я в шоке. Это настолько нелогично, когда процедура работает от другого имени даже не требуя авторизации...

Сделаю модификацию таблиц с учетом прав на уровне процедур и все!
СПАСИБО! (здесь смайлик с пивом )

З.Ы. Это не глюк мускуля или его фича?

[RXL]

Я с этими возможностями не работа - подсказать как и что не смогу. Мне пока хватало возможностей ветки 3.23.

[RXL]

CREATE PROCEDURE sp_name ([proc_parameter[,...]])
[characteristic ...] routine_body

CREATE FUNCTION sp_name ([func_parameter[,...]])
RETURNS type
[characteristic ...] routine_body

proc_parameter:
[ IN | OUT | INOUT ] param_name type

func_parameter:
param_name type

type:
Any valid MySQL data type

characteristic:
LANGUAGE SQL
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
| COMMENT 'string'

routine_body:
Valid SQL procedure statement

..........

The SQL SECURITY characteristic can be used to specify whether the routine should be executed
using the permissions of the user who creates the routine or the user who invokes it. The default
value is DEFINER. This feature is new in SQL:2003. The creator or invoker must have permission
to access the database with which the routine is associated. As of MySQL 5.0.3, it is necessary to
have the EXECUTE privilege to be able to execute the routine. The user that must have this privilege
is either the definer or invoker, depending on how the SQL SECURITY characteristic is set.

Пользователя можно идентифицировать через ф-ию USER() - выдает user@host