Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
06.10.2016, 15:07
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
Друзья, собственно сабж планируется как в PostgreSQL? https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 15:31
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
HS, я в планах на 4.0 ничего такого не наблюдаю. Хотя изначально там и SQL SECURITY {DEFINER | INVOKER} не планировалось, так что возможно и будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 15:54
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
HSДрузья, собственно сабж планируется как в PostgreSQL? https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html бессмысленная фича ИМХО - разработчики баз элементарным разграничением прав не заморачиваются (в силу неграмотности) не вижу профита ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:05
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
MaratIsk, если кому-то плевать на безопасность, то это не значит что плевать всем. Фича в принципе полезная, но существует простой workaround: отбираешь права на SELECT у таблиц и делаешь вьюхи с фильтрацией, а потом работаешь только через эти вьюхи. Кстати в этом обходном пути есть даже преимущество, можно обойти в случае необходимости ограничение в ХП, работая в них с таблицей напрямую (ХП конечно надо будет дать права на SELECT). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:22
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
Денис, Тут бритва Оккама в полный рост - зачем плодить вьюхи - согласитесь, отдает слегка проктостоматологией, если того же можно достичь безопасностью. Понимаю, что условным 95% это не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:29
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
А почему бы просто в GRANT/REVOKE не сделать для SELECT, UPDATE, INSERT также, как для REFERENCES(<список_полей>)? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:31
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, ты не понимаешь о чём речь. Читай каждое слово Row Level Security ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:32
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, ДЛЯ СТРОК. Вот, к примеру, Марат не видит профита - ему запрещен селект на половину строк таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:34
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
HS ... собственно сабж планируется как в PostgreSQL? https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html если такое будет, то будет совсем неплохо. С подобными задачами сталкивался в системах, наворачивали свои обертки. В любом случае, наличие различных вариантов решения задачи - это всегда только плюс. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:47
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
HSДЛЯ СТРОКПонятно. Но, ИМХО, это может существенно сказаться на производительности сервера не в лучшую сторону. Если кому-то для отдельной таблицы (например, в БД документооборота) понадобится такая фича, можно вполне обойтись get/set хранимыми процедурами. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:53
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, ... есть два стула ... В любом случае должно сказаться. Обертка - тоже лишние фетчи. Так что выбор между штатными средствами и оберткой. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 16:53
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
Hello, Rdb Dev! You wrote on 6 октября 2016 г. 16:53:12: Rdb Dev> можно вполне обойтись get/set хранимыми процедурами. Чушь. Модератор: cencored ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:00
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
HSТак что выбор между штатными средствами и оберткой.Если уж делать такую фичу, то с возможностью её включения/отключения для каждой БД в отдельности через gfix. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:02
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, Включение-выключение уже реализовано через -shutdown ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:05
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
WildSeryВключение-выключение уже реализовано через -shutdownРеализовано через -shutdown включение/отключение чего? Row Level Security или самой базы? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:05
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, второй раз повторяю, ты не шаришь. Хоть бы глянул ссылку что ли, прежде чем говорить. Политики создаются отдельно для каждой таблицы через SQL и через него же удаляются (выключаются). ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:10
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
Симонов ДенисПолитики создаются отдельно для каждой таблицы через SQL и через него же удаляются (выключаются).И при этом сервер для любой таблицы проверяет, задана ли политика, а если в базе эта фича не используется совсем, то имеем бесполезный overhead? Не лучше ли для такой базы отключить эту фичу совсем? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:12
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
Симонов Денися в планах на 4.0 ничего такого не наблюдаю. Хотя изначально там и SQL SECURITY {DEFINER | INVOKER} не планировалось, так что возможно и будет. Там и mandatory-то фичи уже в глубоком отставании от таймлайна, а ты надеешься, что кто-то совсем левые замержит?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:13
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, феерический бред. По твоей логике триггеры надо тоже запретить совсем, потому что при каждой операции модификации надо проверять не существует ли триггер. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:14
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_devа если в базе эта фича не используется совсем, то имеем бесполезный overhead? Не имеем. Один if булевого флага погоды не сделает. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:16
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
Dimitry Sibiryakov, не надеюсь. Но мало ли кто-нибудь из Red Soft запилит. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:17
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
Симонов Денис, триггеры есть практически всегда, даже если у таблицы всего два поля и одно из них PK. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:20
|
|||
---|---|---|---|
Row-Level Security, Row Security Policies |
|||
#18+
Dimitry SibiryakovНе имеем. Один if булевого флага погоды не сделает.Фетчи из "хранилища" политик не в счет? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:24
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_dev, Наличие политик можно проверить на этапе препарирования запроса и запомнить в кеше метаданных. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.10.2016, 17:24
|
|||
---|---|---|---|
|
|||
Row-Level Security, Row Security Policies |
|||
#18+
rdb_devФетчи из "хранилища" политик не в счет? Конечно нет. Зачем фетчить что-то из "хранилища политик", если для таблицы политика не установлена? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=40&tablet=1&tid=1561890]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
90ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 211ms |
0 / 0 |