разграничить права доступа к отдельным записям по группам юзеров

← →
yaJohn (2004-07-06 20:59) [0]

Необходимо разграничить права доступа к отдельным записям таблицы по группам юзеров.
Права - чтение, запись, изменение прав доступа. Права, само собой могут менятся админом.

А теперь вопросы:
1) В каких БД есть на то стандартные средства (за ключевое слово к F1 буду премного обязан).
2) Есть ли типовые решения для БД не поддерживающих разграничения прав доступа?

З.ы. Все должно быть на чистом SQL.

← →
Vemer © (2004-07-06 23:51) [1]

Насколько я понимаю в IB/FB этого можно добиться, разграничив права к ХП, которые читают/пишут в таблицы, а сами таблицы ес-но закрыть.. Все стандартными средствами на уровне сервака ес-но..

← →
Johnmen © (2004-07-07 09:38) [2]

>yaJohn (06.07.04 20:59)

1) GRANT
2) О каких типах БД речь ?

← →
asp © (2004-07-07 09:51) [3]

В DB2 можно решить след. образом:
1. Например, имеем таблицу:
CREATE TABLE TABLE1
(ID CHARACTER(13) FOR BIT DATA NOT NULL DEFAULT "",
DEPOT SMALLINT CHECK (DEPOT IS NOT NULL),
...
PRIMARY KEY (ID),
FOREIGN KEY (DEPOT) REFERENCES DEPOT (ID) ON DELETE RESTRICT)

2. На данном примере создаем таблицу привилегий по DEPOT
CREATE TABLE USER_DEPOT
(DEPOT SMALLINT NOT NULL,
USER_NAME VARCHAR(32),
GROUP_NAME VARCHAR(32),
READONLY CHARACTER(1) CHECK (READONLY IS NOT NULL AND READONLY IN "Y", "N"),
CONSTRAINT USER_DEPOT0 CHECK ((USER_NAME IS NOT NULL AND GROUP_NAME IS NULL) OR (USER_NAME IS NULL AND GROUP_NAME IS NOT NULL)))

3. Пишем UDF на определение принадлежности пользователя группе
USER_IN_GROUP(USER_NAME, GROUP_NAME). Результат - "Y", "N".

4. Создаем просмотр для чтения данных
CREATE VIEW VIEW1 AS
SELECT Q1.* Q2.READONLY
FROM TABLE1 Q1
INNER JOIN USER_DEPOT Q2 ON (Q2.DEPOT = Q1.DEPOT)
WHERE Q2.USER_NAME = USER
OR USER_IN_GROUP(USER, Q2.GROUP_NAME) = "Y"

5. Даем привилегию SELECT ON VIEW1 всем пользователям
GRANT SELECT ON VIEW1 TO GROUP PUBLIC

6. Создаем просмотр для модификации данных
CREATE VIEW VIEW1_E AS
SELECT Q1.*
FROM TABLE1 Q1
WHERE Q1.DEPOT IN
(SELECT Q2.DEPOT
FROM USER_DEPOT Q2
WHERE Q2.READONLY = "N"
AND (Q2.USER_NAME = USER
OR USER_IN_GROUP(USER, Q2.GROUP_NAME) = "Y"))
WITH LOCAL CHECK OPTION

7. Изменять будем VIEW1_E
GRANT SELECT, UPDATE, INSERT, DELETE ON VIEW1_E TO PUBLIC

← →
Johnmen © (2004-07-07 09:54) [4]

>asp © (07.07.04 09:51) [3]

Учти один момент. Использование УДФ это огромная дыра в безопасности, за которую и идет борьба...:)

← →
asp © (2004-07-07 09:59) [5]

> Johnmen © (07.07.04 09:54) [4]
То есть, начинается "грязный" SQL? :)

← →
yaJohn (2004-07-07 10:00) [6]

Вау! Огромное спасибо!!!

← →
Johnmen © (2004-07-07 10:02) [7]

>asp © (07.07.04 09:59) [5]

Не понял...

← →
Соловьев © (2004-07-07 10:05) [8]

> З.ы. Все должно быть на чистом SQL.

http://www.ibase.ru/devinfo/sqlroles.htm

← →
asp © (2004-07-07 10:09) [9]

> Johnmen © (07.07.04 10:02) [7]
Автор вопроса желает решить проблему на чистом SQL. Это так, словоблудие.
Мне непонятно, где дыра в безопасности при использовании UDF?

← →
Johnmen © (2004-07-07 10:28) [10]

>asp © (07.07.04 10:09) [9]

Дыра в том, что можно подложить др. длл-ку с той же функией, но работающей, как мне, злоумышленнику, надо...:)

← →
Курдль © (2004-07-07 10:33) [11]

> yaJohn (06.07.04 20:59)
> Необходимо разграничить права доступа к отдельным записям
> таблицы по группам юзеров.
> 1) В каких БД есть на то стандартные средства (за ключевое
> слово к F1 буду премного обязан).
> 2) Есть ли типовые решения для БД не поддерживающих разграничения
> прав доступа?

Такие средства, насколько я знаю, есть только у Оракла, и то с подвыподвертом.
Но (не обижайтесь) я считаю, что в 99.99% такая надобность (если я правильно понял - управлять доступом к отдельным записям) возникает при грубых ошибках в проектировании БД.

← →
asp © (2004-07-07 10:37) [12]

> Johnmen © (07.07.04 10:28) [10]
Ну, если все ворота сервера открыты, то можно :)

> Курдль © (07.07.04 10:33) [11]
Тогда как же:
Имеем кучу подразделений и документы к ним относящиеся. Необходимо раздать пользователям доступ для работы с документами на уровне подразделений.
Предложения? Или это отнесем к 0.01%?

> asp © (07.07.04 10:44) [13]
> Имеем кучу подразделений и документы к ним относящиеся.
> Необходимо раздать пользователям доступ для работы с документами
> на уровне подразделений.
> Предложения?

Да не "предложения", а "РЕШЕНИЯ". Что, я ни разу такого не делал, что ли? :)
Есть таблица документов, связянная "много-к-одному" с таблицей "типы документов". В последней есть флаги ролей - какой роли разрешено работать с данным типом. Далее - по вкусу.

← →
yaJohn (2004-07-07 17:19) [16]

Огромное спасибо всем, кто откликнулся.
>какой роли разрешено работать с данным типом. Далее - по вкусу.
Вот в этом "по вкусу" и кроется, по сути, вопрос. Решения [2], [3] и [8] несомненно правильные.
Но. В условиях задачи не оговаривалась конкретная база. Т.е. может быть (надеюсь что до этого
не дойдет) что ею окажется, например, Access. Именно отсюда мой второй вопрос о типовом решении.
Т.е. решении без хранимых процедур тригеров и GRANT.

>возникает при грубых ошибках в проектировании БД
Вот именно их я и пытаюсь избежать ;) Пуганая ворона забалаговременно выжигает кусты напалмом.

> [14] Курдль © (07.07.04 10:48)
> Да не "предложения", а "РЕШЕНИЯ". Что, я ни разу такого
> не делал, что ли? :)
> Есть таблица документов, связянная "много-к-одному" с таблицей
> "типы документов". В последней есть флаги ролей - какой
> роли разрешено работать с данным типом.

Я что-то не понял.
Так а как же тут предлагается разграничить доступ к отдельным документам? Или я что-то пропустил??

разграничить права доступа к отдельным записям по группам юзеров Найти похожие ветки