perforce: управление разрешениями без участия суперпользователя

Мы используем perforce в моей компании и сильно полагаемся на него. Мне нужно некоторое предложение для следующего сценария:

Наша структура Depot выглядит примерно так:

//depot
    /product1
        /component1
        /component2
        .
        .
        /componentN
            /*.java
            /*.xml
    /product2
        /component1
        /component2
        .
        .
        /componentN
            /*.java
            /*.xml

Каждый продукт состоит из нескольких компонентов, и каждый компонент состоит из java, xml или какого-либо другого программного файла. С каждым компонентом связан менеджер/владелец.

Прямо сейчас мы заблокировали разрешения на запись для каждого пользователя, и только когда это одобрено менеджером/владельцем после проверки кода, мы открываем разрешение на запись для этого пользователя для регистрации любого файла/папки. Этот процесс становится немного неаккуратным. потому что менеджер / разработчик должен ждать, пока администратор perforce разрешит разрешения (обновить таблицу защиты perforce). Кроме того, мы даем им всего 24 часа для проверки (из-за гибкости, в которой я мало что понимаю :)), после чего мы должны снова заблокировать доступ на запись для этого пользователя.

Я ищу механизм, в котором администраторы perforce могут делегировать эту ответственность соответствующим менеджерам/владельцам, не предоставляя им права суперпользователя или администратора, и который автоматически отключает разрешение на запись через 24 часа.

Какие-либо предложения ?

Заранее спасибо.


version-control perforce p4v
person Raghuveer    schedule 03.11.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Там нечего делать из коробки, как таковой.

Самое близкое, что я могу придумать, это если бы основная версия этих компонентов была разрешена группой с владельцем. Владелец группы может добавлять и удалять участников из группы, тем самым делегируя разрешения «привратнику», а не самим администраторам.

Дайте мне знать, если вам потребуются дополнительные разъяснения по этому поводу.

person Blaskovicz    schedule 03.11.2012
comment
Большое спасибо за это. Я получил идею. Позвольте мне подробнее изучить этот вариант. - person Raghuveer; 04.11.2012

arrow_upward
1
arrow_downward

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

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

Затем установите инструмент на сервер безопасным способом, предоставив инструменту права на обновление таблицы защиты, и попросите администраторов компонентов использовать инструмент для управления разрешениями.

Например, я видел, как это делается путем написания небольшого веб-приложения, например, на Java или Perl, установки его на веб-сервере на защищенной машине и предоставления администраторам компонента возможности управлять этим инструментом через веб-интерфейс.

Все, что должен предоставить ваш инструмент, это (а) простой механизм входа/выхода из системы для администраторов ваших компонентов (веб-сервер может уже сделать это за вас), (б) команда, которая принимает имя пользователя и имя папки и предоставляет разрешение, и (c) команду (или таймер), которая впоследствии удаляет эти разрешения.

person Bryan Pendleton    schedule 03.11.2012
comment
Спасибо за ответ. Ваша идея очень хороша. Я также заметил еще одну информацию в приведенном выше ответе. Я, вероятно, объединим обе эти идеи, чтобы придумать инструмент. Еще раз спасибо за ваши подробные шаги. Это действительно поможет мне. - person Raghuveer; 04.11.2012