« Назад

Используем RBAC: предоставление пользователям доступа в Solaris zones

В рамках запуска стенда для лабораторного практикума возникла закономерная необходимость предоставления доступа пользователям в зоны.

Учитывая наличие у всех зон доступа к общей подсети, можно было бы обойтись предоставлением доступа в зону по ssh. Но есть несколько "но":

  • для предоставления доступа необходимо вносить изменения (в .ssh/authrized_keys или изменение пароля) на каждой предоставляемой студенту зоне;
  • если в результате ошибки студента потребовалось вернуть зону в состояние по умолчанию, эти изменения необходимо будет повторить;
  • ошибка студента может привести к недоступности зоны через общую сеть и потребовать вмешательства преподавателя;
  • некоторые варианты задания предполагают отключение части зон от общей подсети, что вносит дополнительные сложности для студентов и увеличивает вероятность ошибки при доступе по ssh.

Альтернативным способом доступа к зонам является использование zlogin(1). Но без дополнительных действий простому пользователю воспользоваться ей не получится:

$ zlogin z102
zlogin: You lack sufficient privilege to run this command (all privs required)

Сообщение как бы намекает на то, что пользователю не хватает прав. Согласно man zonecfg выдать пользователю эти права на вход не просто, а очень просто:

# zonecfg -z z102
zonecfg:z102> add admin
zonecfg:z102:admin> set user=student1
zonecfg:z102:admin> set auths=login,manage
zonecfg:z102:admin> end
zonecfg:z102> commit

Но после выполнения последней команды внезапно появляется сообщение:

LDAP configuration problem.
ldap update userattr database failed for student1.
UX: /usr/sbin/usermod: ERROR: Cannot update system - login cannot be modified.

Учитывая то, что пользователи хранятся в LDAP, это в каком-то смысле даже логично, но тем не менее.

Более подробное изучение происходящего привело к понимаю того, что zlogin использует Role Based Access Control (RBAC), появившийся еще в Solaris 10, но (почему-то) не нашедшего широкого применения в массах. Для локальных пользователей дополнительные атрибуты пользователя записываются в файл /etc/user_attr.

Для пользователей, хранящихся в LDAP, всё оказалось еще проще. Информацию о дополнительных атрибутах можно хранить прямо в записи самого пользователя, назначив ему дополнительный класс SolarisUserAttr, и записав в атрибут SolarisAttrKeyValue нужное значение, синтаксически повторяющее содержимое файла user_attr. Таким образом, для разрешения пользователю student1 управлять зонами z102 и z104 необходимо изменить его запись в LDAP, что через ldapmodify делается так:

dn: uid=student1,ou=people,dc=tune-it,dc=ru
changetype: modify
add: objectClass
objectClass: SolarisUserAttr
-
add: SolarisAttrKeyValue
SolarisAttrKeyValue: auths=solaris.zone.login/z102,solaris.zone.manage/z102,
 solaris.zone.login/z104,solaris.zone.manage/z104;
 profiles=Zone Management

После чего пользователь сможет получить доступ к зоне командой:

$ pfexec zlogin z102

Небольшая тонкость с изменением данных напрямую в LDAP связана с существованием в Solaris довольно агресивного Name Service Cache Daemon (nscd), который может закешировать устаревшую информацию. Для того, чтобы nscd обновил текущую информацию о пользовательских атрибутах необходимо выполнить команду:

# nscd -i user_attr

Убедиться в том, что информация обновилась можно, например, с помощью команды:

$ auths student1

А отобрать у пользователя права через ldapmodify можно так:

dn: uid=student1,ou=people,dc=tune-it,dc=ru
changetype: modify
delete: objectClass
objectClass: SolarisUserAttr
-
delete: SolarisAttrKeyValue

Разрешение своему пользователю доступа ко всем зонам, и, заодно, получение возможности стать суперпользователем командой su -, в ldapmodify потребуется указать:

dn: uid=admin1,ou=people,dc=tune-it,dc=ru
changetype: modify
add: objectClass
objectClass: SolarisUserAttr
-
add: SolarisAttrKeyValue
SolarisAttrKeyValue: auths=solaris.zone.login,solaris.zone.manage;
 profiles=Zone Management;roles=root

Всё очень просто и интуитивно понятно.

P.S. Внимательно посмотрев в журналы LDAP сервера:

[19/Aug/2013:11:53:06 +0400] conn=294258 op=2 msgId=3 - SRCH
 base="ou=people,dc=tune-it,dc=ru" scope=1
 filter="(&(objectClass=SolarisUserAttr)(uid=admin1))"
 attrs="uid SolarisUserQualifier SolarisAttrReserved1 SolarisAttrReserved2
  SolarisAttrKeyValue"

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



Пока нет комментариев. Создать новый.