• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

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

    Запись на курс до 25 апреля. Получить промодоступ ...

"доверие" Прав Другой Учетки На Документы В Бд

  • Автор темы Dragon108
  • Дата начала
D

Dragon108

Долго думал куда написать, в программирование или сюда. Решил сюда, поскольку тема, на мой взгляд, носит больше админский характер, нежели разработческий ...
Начну с общеизвестных фактов: Для того что бы разграничивать доступ к документам в базе, существуют поля Authors и Readers, соответственно туда прописываются Notes-имена тех людей, кто сможет читать и редактировать данный документ (при условии что ACL бд для этих людей настроена должным образом...) - ну это, повторюсь, общеизвестно
Вопрос заключается в другом - например у нас есть человек, он имеет какой-либо (авторский, либо ридерский доступ к документу) и тут подходит время его, например, отпуска, соответственно все эти документы он на время своего отпуска хочет отдать другому человеку, например, одному из своих подчиненных, так сказать - "передать дела" - Понятно что это можно реализовать программно: например, написать агента, который бы крутился ночью и обновлял/добавлял (создавал бы новые авторские и ридерские поля, куда бы записывал этого подчиненного) доступ ко всем документам ... Но, меня не покидает надежда :( что может у Лотуса где-нибудь в настройках сервера, или может быть учетки, или учетной записи на сервере есть такая настройка, в которой бы эта учетная запись могла бы, так скажем, "доверять" другой учетной записи свои права на документы в базах на этом сервере? Т.е. дать доступ к документу не меняя его авторских и ридерских полей. Знающие люди, подскажите плиз, можно ли такое сделать или об этом можно забыть и спокойно писать агента.
Заранее спасибо.
 
N

nvyush

Можно в авторы/читатели записывать не имена, а роли/группы.
 
W

wertep

Можно в авторы/читатели записывать не имена, а роли/группы.
Точно создать на каждого чела по группе, а потом просто всех заместителей пихать в эту группу. К тому же документообороты имеют привязку конкретной персоны к лотусовому пользователя, вот в приязку и запихивать группу.

Идея конечно интересная, но вот на вкус ...
 
R

RAJ

Точно создать на каждого чела по группе, а потом просто всех заместителей пихать в эту группу. К тому же документообороты имеют привязку конкретной персоны к лотусовому пользователя, вот в приязку и запихивать группу.

Идея конечно интересная, но вот на вкус ...


когда столкнетесь с ограничением количества ролей(около 70), такое решение интересным не покажется(как по мне)
 

Мыш

Lotus Team
12.02.2008
1 219
29
BIT
66
когда столкнетесь с ограничением количества ролей(около 70), такое решение интересным не покажется(как по мне)
Согласен. Группы, вроде, лучше. По крайней мере, на сотнях юзеров сотни групп живут (6.5.x и 8.5.x).
ЗЫ. Не без глюков - в плане кеширования доступа. :)
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
Минус групп в секурности в распределенной среде. Однако плюсы однозначно перевешивают все минусы. Вариант: имя группы есть табельный номер\СНИЛС сотрудника :)
 
W

wertep

когда столкнетесь с ограничением количества ролей(около 70), такое решение интересным не покажется(как по мне)
Я ни где не вел речи о ролях. Практически в каждом документообороте есть кадровая база, в которой прописано что "Иванов Петр Сидорович" это пользователь "Petr Ivanov/domino". Вот и предлагалось вместо "Petr Ivanov/domino" прописывать "PetrIvanovGroup/domino", а вот в эту группу и писать самого Иванова и всех замещающих.

ПыСы. И да мне эта идея тоже не нравится.
 
N

nvyush

В кадровой базе помимо сотрудников должны быть также и их должности. Логичнее было бы давать права не группе "PetrIvanovGroup/domino", а группе "ChiefOfHRDep" и т.п. Только групп при таком подходе будет много. Зато не надо будет "лопатить" документы при назначении на соответствующую должность другого сотрудника.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!