2
Как вы используете код интеграции/интеграции, требующий другого уровня привилегий, чем существует в вашей среде непрерывной интеграции?Автоматическое тестирование привилегированных операций
В моей среде без полномочий root, CCRB -driven build, у меня есть некоторые служебные функции, которые предполагают привилегии, которые не хранятся в моей автоматической среде сборки: либо привилегии root, либо специальные учетные записи и группы. (Например, одна функция изменяет UID/GID и дополнительные группы на указанную учетную запись, меняет корень и текущий рабочий каталог и разводится с любого управляющего терминала.)
Мы могли бы провести тесты вручную, конечно, но затем мы могли бы забыть их запустить.
Как другие решают эту проблему?
Можете ли вы прояснить, например, как вы проверили функцию, предназначенную для вызова как root, которая изменяет UID/GID, рабочий каталог и корень файловой системы? – pilcrow
@pilcrow, как я уже сказал, я попытался скрыть все эти функционалы за макетируемыми интерфейсами, с двумя реализациями: реальным, который будет использоваться в производстве, и макетной реализацией, предназначенной для модульного тестирования, которая может быть предварительно сконфигурирована для вернуть необходимые значения (ы) и позволить мне распознавать вызовы методов и значения параметров. Таким образом, в моей тестовой среде я мог «проверять» все привилегии, которые мне нужны, и я мог бы почувствовать, что правильные методы вызываются с правильными параметрами без побочного эффекта фактически изменяющегося состояния системы. –
éter, это «код управления безопасностью», который я хочу проверить. Я не хочу насмехаться над проверкой того, что я потерял ложные привилегии, я хочу проверить, действительно ли я сбросил фактические привилегии. – pilcrow