Глава 2. Передача полномочий и джейлы

Разработчики ZFS сделали практически всё от них зависящее, чтобы облегчить управление хранением данных для системных администраторов. Один из лучших способов уменьшения объёма работы, который вы должны сделать, состоит в том, чтобы заставить кого- то ещё выполнить её для вас. ZFS имеет полностью функционирующую систему передачи полномочий, которая позволяет вам предписывать какие команды и функции пользователь или группа пользователей могут применять для каждого набора данных. Вы можете позволить пользователям создавать и разрушать их собственные снимки, создавать дочерние наборы данных, генерировать отчёты о потреблении пространства или управлять свойствами набора данных. ZFS строится на функциональности предоставления полномочий (delegation) для предоставления особой поддержки джейлам.

 Передача полномочий ZFS

ZFS делает возможным предоставление полномочий (delegate) административных задач пользователям на основе отдельных свойств и отдельных команд для каждого набора данных. Вы можете предоставить администратору базы данных полное управление над пулом базы данных, или для администратора веб- сервера управление над снимками набора данных веб- сайта. Для предоставления полномочий применяйте команду zfs allow.

Предоставление zfs allow пул или набор данных в качестве аргумента, отображает полномочия на этом устройстве. Здесь я поучаю полномочия на пуле remotepool.


# zfs allow remotepool
---- Permissions on remotepool -------------------------
Local+Descendent permissions:
 user replicator compression,create,destroy,mount,mountpoint,receive
 	   

Данный пул имеет единственную запись полномоий, для пользователя replicator. Этот пользователь имеет права для свойств compression и mountpoint, а также для подкоманд ZFS create, destroy, mount и receive. (Глава 4 обсуждает важность этих определённых полномочий.)

Приложения и пользователи могут определять свои собственные свойтсва. Программы, подобные zfstools создают свойства для управления снимками. Также существует специальное свойство, userprop, для разрешения пользователям создавать определяемые пользователем свойства. Определяемые пользователем свойства назначаются как разовое полномочие: вы не можете назначать различные определяемые пользователем полномочия поодиночке.

Хотя root не перечислен как имеющий какие- то полномочия здесь, root может делать всё, что он только чертовски не пожелает. Потому что это то, как вращается Unix.

  Добавление передачи полномочий

Передадим полномочия на пул или набор данных пользователю или группе. Флаг -u позволяет вам определять имя пользователя для zfs allow, а -g предписывает группу.


# zfs allow -u username permissions pool/dataset
 	   

Допустим, у нас есть причиняющий беспокойство пользователь, назовём его Лукас. (Я нисколько не сомневаюсь, что когда Джуд писал этот раздел, он думал о каком- то другом Лукасе, отличном от меня ==mwl). Он продолжает пытаться выполнять глупые трюки Unix, которые выжигают его домашний каталог. Давайте позволим Лукасу создавать его собственные снимки таким образом, чтобы он не мог беспокоить системного администратора всякий раз, когда он разрушает своё окружение.


# zfs allow -u lucas snapshot,rollback \
      mypool/usr/home/lucas
 	   

Когда вы просмотрите полномочия этого набора данных, отобразятся два назначенных вами пономочия.


# zfs allow mypool/usr/home/lucas
---- Permissions on mypool/usr/home/lucas -------------
Local+Descendent permissions:
     user lucas rollback,snapshot
 	   

Предоставление полномочий автоматически наследуется. Когда Лукас получает возможность делать снимок своего набора данных домашнего каталога, он также получает эти полномочия на все дочерние наборы данных в своём домашнем каталоге. По ряду причин он имеет набор данных с названием blackmail. Вероятно, это то место где он припрятывает все фотографии и записи, которые он использует для получения разработчиков BSD, которые помогают ему с научно- исследовательскими и техническими обзорами. (Не все такие материалы. И определённо какой-то другой Лукас ==mwl)


# zfs allow mypool/usr/home/lucas/blackmail
---- Permissions on mypool/usr/home/lucas --------------
Local+Descendent permissions:
     user lucas rollback,snapshot
 	   

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


# su lucas
$ zfs snapshot \
mypool/usr/home/lucas/blackmail@bsdcan_drunken_escapades
$ zfs list -t all -r -o name mypool/usr/home/lucas
NAME
mypool/usr/home/lucas
mypool/usr/home/lucas/blackmail
mypool/usr/home/lucas/blackmail@bsdcan_drunken_escapades
 	   

Мы знаем, это работает. Давайте избавимся от снимка до того, как у Лукаса появятся идеи, которых он уже не имеет.


$ zfs destroy \
mypool/usr/home/lucas/blackmail@bsdcan_drunken_escapades
cannot destroy snapshots: permission denied
 	   

Создание нового набора данных затрагивает его монтирование, а разрушение набора данных, очевидно, должно включать его размонтирование. Чтобы быть полезными, всем командам clone, create и destroy необходимы полномочия mount. Чтобы предоставить lucas полномочия, выполните zfs allow -u lucas и выведите перечень требуемых полномочий и набора данных.


# zfs allow -u lucas destroy,mount mypool/usr/home/lucas
 	   

Проверка вашей работы теперь отображает все полномочия, которые вы назначили в обоих выполнениях zfs allow.


# zfs allow mypool/usr/home/lucas
---- Permissions on mypool/usr/home/lucas --------------
Local+Descendent permissions:
     user lucas destroy,mount,rollback,snapshot
 	   

Теперь Лукас может выстрелить себе в ногу разрушив свой домашний каталог расположенный там. {Прим. пер.: "Он получил спортивную травму во время тренировки по гандболу на прошлой неделе, несколько дней был на больничном, вчера вышел на работу, сегодня провёл селекторное совещание по космодрому Восточный".} И конечно он волен {написать в instagramm} и поплакаться об этом.

Вы можете предоставить пользователю полномочия создавать и монтировать набор данных, однако операционная система также имеет своё мнение в этом вопросе. FreeBSD применяет sysctl vfs.usermount для определения того, могут ли пользователи монтировать разделы. Установите этот sysctl в значение 1 чтобы разрешить пользователю монтироать разделы.

Даже с таким sysctl дозволение обычному пользователю монтировать файловые системы поставляется в комплекте с ремнём безопасности, котрый блокирует пользователя в выполнении злонамеренных вещей. Пользователь должен быть владельцем каталога, в котором он хочет смонтировать что бы то ни было. Это предотвращает монтирование пользователями своих новых наборов данных в виде /etc с последующим взломом вашей системы. Набор данных может иметь строгие полномочия, однако только пользователь, который владеет точкой монтирования и имеет полномочия на монтирования в ней может выполнять её монтирование.

Чтобы разрешить пользователю lucas создавать, клонировать и монтировать наборы данных в его домашнем каталоге, установите sysctl и убедитесь, что он владеет тем каталогом, которым вы позволите ему управлять.


# sysctl vfs.usermount=1
# zfs allow -u lucas create,clone,mount \
      mypool/usr/home/lucas
 	   

Зарегистрируйтесь в качестве lucas снова чтобы проверить что это работает.


# su lucas
$ zfs create mypool/usr/home/lucas/evil_plot
$ zfs mount
mypool/ROOT/default              /
…
mypool/usr/home                  /usr/home
mypool/usr/home/lucas            /usr/home/lucas
mypool/usr/home/lucas/blackmail  /usr/home/lucas/blackmail
mypool/usr/home/lucas/evil_plot  /usr/home/lucas/evil_plot
 	   

Не забудьте добавить vfs.usermount=1 в его /etc/sysctl.conf чтобы он всё ещё мог монтировать наборы данных после перезагрузки, иначе он прдёт к вам поскулить.

  Изъятие передачи полномочий

Предоставление полномочий (и работы) на сторону другим людям может быть освобождением, но ничто не сравнится с ощущением от отнятия полномочий назад. Для удаления полномочий применяйте zfs unallow . Эта команда в точности соответствует синтаксису zfs allow .

Здесь lucas создал слишком много потомков и мы решили, что ему больше нельзя позволять деторождение. Давайте избавим его от полномочий create.


# zfs unallow -u lucas create mypool/usr/home/lucas
# zfs allow mypool/usr/home/lucas
---- Permissions on mypool/usr/home/lucas --------------
Local+Descendent permissions:
     user lucas clone,destroy,mount,rollback,snapshot
 	   

Полномочия также могут удаляться рекурсивно, при помощи флага -r, что обеспечит гарантию того, что полномочия удаляются даже из тех отдалённых дочерних наборов данных, в которых вы могли бы вручную установить некие полномочия.

 Наследование передачи полномочий

Передача полномочий ZFS автоматически наследуется. Если вы предоставите пользователю полномочия на zroot/db, она автоматически получает те же самые полномочия на всех детей zroot/db. Подкоманда zfs allow может также ограничить наследование полномочий. Наследование полномочий может быть локальным или применяться к потомкам.

Полномочия Лукас применены только к определённому набору данных. Мы можем позволить lucas полномочия на снимок zroot/usr/home/lucas, но не на снимок дочерних наборов данных. Он должен управлять своими материалами шантажа старым способом. Установите привелегие только на локальные при помощи флага -l.


# zfs allow -lu lucas clone,destroy,mount,rollback,snapshot zroot/home/lucas
 	   

Полномочия теперь отображаются только как локальные, вместо того чтобы быть локальными и наследуемыми.


# zfs allow zroot/home/lucas
---- Permissions on zroot/home/lucas -------------------
Local permissions:
     user lucas clone,destroy,mount,rollback,snapshot
 	   

Вы можете также применить полномочия только к дочерним наборам данных, а не к набору данных в своей команде. Флаг -d предписывает zfs allow что полномочия применяются только к потомственным наборам данных, а не к самому их родителю для которого эти полномочия были созданы.

Здесь я хочу разрешить lucas разрушать созданные им снимки, но при этом не разрушать весь его домашний каталог. Я применяю -d для предписания того, что эти полномочия применяются только к потомственным наборам данных его домашнего каталога, а не к самому домашнему каталогу. Я оставляю полномочия для команд snapshot и rollback на месте в его домашнем каталоге, поэтому он сможет спасти себя сам, если не закрутит слишком сильно.


# zfs allow -d lucas destroy,mount mypool/usr/home/lucas
# zfs allow mypool/usr/home/lucas
---- Permissions on mypool/usr/home/lucas -------------
Descendent permissions:
     user lucas destroy,mount
Local+Descendent permissions:
     user lucas rollback,snapshot
 	   

И вновь выдадим себя за Лукаса и проверим полномочия.


$ zfs destroy -v mypool/usr/home/lucas/desc
will destroy mypool/usr/home/lucas/desc
$ zfs destroy -v mypool/usr/home/lucas
cannot unmount ‘/home/lucas’: Operation not permitted
 	   

Выполнение zfs destroy в домашнем каталоге Лукаса теперь с удовольствием зарезервировано для системного администратора.

 Полномочия времени создания

ZFS позволяет вам создавать полномочия сегодня для наборов данных, которые не будут существовать вплоть до следующего вторника или какого- то другого времени. Полномочия времени создания (Create time) применяются к пользователю, который создаёт набор данных. Это просто как "липкая наклейка" для передачи полномочий. Определите полномочия Create time при помощи -c.

Обычное пожелание для этого вида полномочий состоит в предоставлении этих полномочий каждому, вместо того чтобы устанавливать каждого пользователя в системе или определять имя группы. Вместо того, чтобы определять -u или -g и имя пользователя или группы, воспользуйтесь флагом -e чтобы указать всех пользователей (everyone).

Применение полномочий времени создания требует аккуратного управления наследованием. Вы хотите полномочия времени создания для применения к дочерним наборам данных, не к родительским. Родительский набор данных должен иметь свои собственные полномочия, устанавливайте применяя -l.

Предположим, у вас есть набор данных рабочей области {scratch}, используемый всеми. Это как /tmp, но с функциональностью ZFS. Мы хотим чтобы все были способны создавать и монтировать наборы данных в этом пространстве, однако не иметь доступа к очистке от мусора всего набора данных. Такие полномочия могут быть ограничены (через флаг -l) этот набор данных и не наследоваться автоматически новыми потомками.


# zfs allow -l -e create,mount mypool/scratch
 	   

Теперь применим -c для определения полномочий времени создания, назначаемые вновь создаваемым наборам данных.


# zfs allow -c snapshot,rollback,destroy mypool/scratch
 	   

Проверка вашей работы покажет полномочия времени создания в наборе полномочий.


# zfs allow mypool/scratch
---- Permissions on mypool/scratch ---------------------
Permission sets:
     destroy,rollback,snapshot
Local permissions:
     everyone create,mount
 	   

Действительный тест, конечно, состоит в выполнении этих команд обычным пользователем. Давайте предоставим lucas создать некие наборы данных в mypool/scratch.


# su lucas
$ zfs create mypool/scratch/lucas
 	   

Это работает, но какие полномочия мы имеем?


$ zfs allow mypool/scratch/lucas
---- Permissions on mypool/scratch/lucas ---------------
Local permissions:
     user lucas destroy,rollback,snapshot
---- Permissions on mypool/scratch ---------------------
Permission sets:
     destroy,rollback,snapshot
Local permissions:
     everyone create,mount
 	   

Теперь lucas, и только lucas, может создавать снимки и разрушать свой набор данных. Другие пользователи могут создавать свои собственные наборы данных, к которым только они имеют доступ.

 Полномочия на изменение полномочий

Пользователь с доступом к команде allow может передавать любые другие полномочия, которые у него уже имеются. Это позволяет вам дать руководителю команды или управляющему проектом возможность делать запас полномочий для своей бригады.

Рассмотрим предыдущий пример набора рабочей области. Предположим, lucas хочет разрешить пользователю litz создание снимков в его новом наборе данных рабочей области.

Вначале дайте lucas возможность передавать полномочия разрешив ему команду zfs allow.


# zfs allow -u lucas allow mypool/scratch/lucas
# zfs allow mypool/scratch/lucas
---- Permissions on mypool/scratch/lucas ---------------
Local permissions:
     user lucas destroy,snapshot
Local+Descendent permissions:
     user lucas allow
---- Permissions on mypool/scratch ---------------------
Permission sets:
     destroy,snapshot
Local permissions:
     everyone create,mount
 	   

Теперь Лукас может предоставлять любые имеющиеся у него полномочия учётной записи litz. Проверим, зарегистрировавшись под его именем.


# su lucas
$ zfs allow -u liz snapshot mypool/scratch/lucas
$ zfs allow mypool/scratch/lucas
---- Permissions on mypool/scratch/lucas ---------------
Local permissions:
     user lucas destroy,snapshot
Local+Descendent permissions:
     user lucas allow
     user liz snapshot
---- Permissions on mypool/scratch ---------------------
Permission sets:
     destroy,snapshot
Local permissions:
     everyone create,mount
 	   

Однако Лукас не может выдать полномочия, которых у него нет:


$ zfs allow -u liz clone mypool/scratch/lucas
cannot set permissions on ‘mypool/scratch/lucas’:
permission denied
 	   

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

 Наборы полномочий

Выполнение zfs allow предоставляет список из белее чем 60 полномочий, которые вы можете предоставлять пользователю. Мы не хотим перечислять здесь их все, однако вы можете предоставлять доступ к каждой подкоманде zfs(8), а также у свойствам каждого пула и набора данных индивидуально.

Вместо того, чтобы предоставлять длинный перечень полномочий каждому пользователю, и при этом неизбежно забыть одно, ZFS делает возможным вам определять наборы полномочий. Примените флаг -s и определите имя набора полномочий, начинающееся со знака @. Затем перечислите полномочия в этом наборе и имя набора данных, для которого будет действительным этот набор полномочий.


# zfs allow -s @permissionset \
      permission,permission,permission… dataset
 	   

Здесь мы создадим набор полномочий с именем @dataset, который содержит полномочия для управления наборами данных. Он применяется к набору данных mypool/teams.


# zfs allow -s @dataset create,destroy,mount,rename,
snapshot,rollback,clone,promote,hold,release \
      mypool/teams
 	   

Приведём набор полномочий с именем @replication, который предлагает необходимые привилегии для репликации на том же самом наборе данных.


# zfs allow -s @replication send,receive mypool/teams
 	   

Набор полномочий @billing предоставляет доступ к обычно недоступным свойствам userused и groupused на этом наборе данных.


# zfs allow -s @billing userused,groupused mypool/teams
 	   

Ниже определяется набор полномочий @quotas, который позволит кому- то управлять квотами пространства.


# zfs allow -s @quotas userquota,groupquota,quota,refquota,reservation,refreservation mypool/teams
 	   

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


# zfs allow -s @basic_properties compression,copies,atime,primarycache,secondarycache mypool/teams
 	   

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


# zfs allow -g managers @dataset,@basic_properties \
      mypool/teams
 	   

А здесь мы разрешаем пользователю lucas, который выполняет доступ к системе биллинга, полномочия биллинга на mypool/teams.


# zfs allow -u billbot @billing mypool/teams
 	   

Выполнение zfs allow отобразит вам наборы полномочий и назначенные на наборе данных полномочия.


# zfs allow mypool/teams
---- Permissions on mypool/teams -----------------------
Permission sets:
@basic_properties atime,compression,copies,
     primarycache,secondarycache
@billing groupused,userused
@dataset clone,create,destroy,hold,mount,promote,
     release,rename,rollback,snapshot
@quotas groupquota,quota,refquota,refreservation,
     reservation,userquota
@replication receive,send
Local+Descendent permissions:
     user billbot @billing
     group managers @basic_properties,@dataset
 	   

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

 Передача полномочий и джейлы

FreeBSD поддерживает метод виртуализации с небольшим весом, именуемый джейлами (jail, дословно: клетками). По применению джейлов вы найдёте большое число руководств, поэтому мы не будем вдаваться в сложности джейлов. (Лукас продолжает настаивать, что он собирается написать книгу "Мастерская джейлов". Печально, но книги по хранилищам находятся где- то между предысторией и предпосылками.) Реализация ZFS FreeBSD имеет специальную поддержку для джейлов.

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

Заключённый в джейл набор данных не может быть смонтирован в вашей хост системе. Набор данных джейла не имеет подтверждённых доверенностей и может иметь установки свойств, которые не совместимы с - или даже активно неприязненны к - хосту. В качестве простейшего примера, джейл может иметь набор данных с mountpoint в /etc. Запомните, что файловые системы BSD выстраиваются в стек. Если ваш хост монтирует такой набор данных джейла, /etc джейла будет в стеке с /etc хоста. Хост, несомненно, должен иметь /etc/password, rc.conf, sshd_config джейла и прочие жизненно важные файлы. В худшем случае системный администратор джейла может заявить свои права на управление вашим хостом. В лучшем случае, системный администратор хоста будет в действительности иметь несчастливый день.

Что касается пользователя root джейла, он может сказать, что он практически полностью управляет набором данных. Единственное свойство, которое он н может изменить, это квота. Изменение квоты может дать ему больший доступ, чем выделял ему системный администратор.

Однако, учётная запись заключённого в джейл root может видеть что он существует в рамках джейла. Учётная запись root может видеть видеть каждый из своих родительских наборов данных вверх до корня пула. Если у вас имеется пул jails, скажем, jails/customers/lucas, тогда пользователь root может просматривать этот путь. Однако, ни не могут видеть другие наборы данных за пределами джейла. Прочие настроенные под пользователей наборы данных являются невидимыми.

  Заключение набора данных в джейл

Чтобы заключить набор данных в джейл, установите свойство jailed в значение on. Хост более не будет способен монтировать это набор данных.

Чтобы построить джейл для Лукаса, создайте новый набор данных, который будет служить корнем его места заключения. Здесь мы используем для такого джейла набор данных zroot/jails/lucas/jail.


# zfs create -o jailed=on -o mountpoint=/jail \
      zroot/jails/lucas/jail
 	   

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


# jail -c path=/zroot/jails/lucas mount.devfs \
allow.mount allow.mount.zfs host.hostname=lucas \
ip4.addr="lo0|127.0.0.2" exec.poststart = \
"/sbin/zfs jail lucas zroot/jails/lucas/jail" \
command=/bin/sh
 	   

Теперь войдите в джейл.


# jexec lucas sh
 	   

Поскольку мы находимся в джейле, мы можем создать новый набор данных.


jail# zfs create zroot/jails/lucas/jail/foo
 	   

Этот новый набор данных, а также наборы данных предков джейла, являются видимыми.


jail# zfs list -o name,mountpoint
NAME                        MOUNTPOINT
zroot                       /zroot
zroot/jails                 /zroot/jails
zroot/jails/lucas           /zroot/jails/lucas
zroot/jails/lucas/jail      /jail
zroot/jails/lucas/jail/foo  /jail/foo
 	   

Имеются ли другие наборы данных в zroot/jails или, на самом деле, в хосте, являющемся основой для данного джейла? Пользователи в этом джейле никогда этого не узнают.

Пользователь lucas теперь может устанавливать точки монтирования, создавать и разрушать наборы данных, передавать полномочия на наборы данных обычным пользователям внутри джейла и тому подобное. Вот бы и в реальном мире так легко было бы удерживать пользователей Лукас от поломки {окружающих их} вещей...

  Построение ZFS передачи полномочий джейлу

Возможно, ваши пользователи не захотят пустого скелетного джейла показанного выше. Вероятно, они хотят реальной пользовательской земли обетованной с программами и возможностями выполнения служб. Это означает установку FreeBSD в набор данных вашего джейла. Джейлы могут быть чрезвычайно сложными, поэтому мы не хотим полностью обсуждать их здесь. Мы выполним базовую установку FreeBSD на набор данных в джейле, поэтому мы можем добавить ZFS в ваши существующие процессы джейла.

Для начала создадим набор данных джейла.


# zfs create -p mypool/jails/lucas/zroot
 	   

Теперь установим в этот набор данных операционную систему. Вы можете выполнить установку с сайта FTP, поскольку мы имеем здесь дело с версией amd64 FreeBSD 10.3.


# fetch -o - ftp://ftp.freebsd.org/pub/FreeBSD/
releases/amd64/10.3-RELEASE/base.txz | \
      tar -xJf - -C /mypool/jails/lucas/
 	   

Если вы собираетесь устанавливать множество джейлов, загрузите base.txz для вашей версии и извлеките его в каждый свой джейл.


# tar -xf base.txz -C /mypool/jails/lucas/
 	   

Когда вы скопируете операционую систему в набор данных джейла, отметьте этот набор данных как не имеющий доверия (untrusted). Это сделает это набор данных недоступным для вашего хоста.


# zfs set mountpoint=/zroot mypool/jails/lucas/zroot
# zfs set jailed=on mypool/jails/lucas/zroot
 	   

В готовом наборе данных сделайте запись для такого джейла в файле настроек джейла, /etc/jail.confЗдесь мы определяем такой джейл.


no.gelato.for.michaelwlucas.com.
 nogelatoforyou {
 host.hostname = "no.gelato.for.michaelwlucas.com";
 ip4.addr = "em0|198.51.100.200";
 path = "/mypool/jails/lucas";
 persist = true;
 mount.devfs = true;
 allow.mount = true;
 allow.mount.zfs = true;
 enforce_statfs = 1;
 exec.poststart = "/sbin/zfs jail nogelatoforyou mypool/jails/lucas/zroot";
 exec.poststop = "/sbin/zfs unjail nogelatoforyou mypool/jails/lucas/zroot";
}
 	   

(Хорошо. Теперь Джуд просто скуп. ==mwl)

Имея такую запись jail.conf на своём месте, мы cможем запускать джейл с применением стандартных инструментов FreeBSD.

Последняя часть установки должна случиться в пределах клетки (джейла). В противном случае вы можете сделать нечто безумное и сумасшедшее наподобие того как спланировать заранее когда устанавливать вашу операционную систему, однако вы бы не получили удовольствия от подобных вещей. Давайте войдём в джейл и просмотрим наши наборы данных.


# jexec nogelatoforyou /bin/sh
jail# zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
mypool                   5.21G  13.1G    96K  none
mypool/jails              180M  13.1G    96K  /mypool/jails
mypool/jails/lucas        180M  13.1G   180M  /mypool/jails/lucas
mypool/jails/lucas/zroot   96K  13.1G    96K  /zroots
 	   

Этот новый джейл не имеет ZFS разрешённой в rc.conf, поэтому новый набор данных не монтируется по умолчанию. Разрешим ZFS и перезапустим данный джейл.


jail# sysrc zfs_enable="YES"
 	   

Выполнив изменения настройки, перезапустите джейл и войдите в него повторно.


# service jail onerestart nogelatoforyou
# jexec nogelatoforyou /bin/sh
 	   

Вы увидите заново созданные наборы данных.


jail# zfs create mypool/jails/lucas/zroot/test
jail# zfs list
NAME                          USED  AVAIL  REFER  MOUNTPOINT
mypool                       5.21G  13.1G    96K  none
mypool/jails                  180M  13.1G    96K  /mypool/jails
mypool/jails/lucas            180M  13.1G   180M  /mypool/jails/lucas
mypool/jails/lucas/zroot      192K  13.1G    96K  /zroot
mypool/jails/lucas/zroot/test  96K  13.1G    96K  /zroot/test
 	   

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

  Определение пределов и ремни безопасности

Но что, если Лукас некомпетентен или является исчадием ада? Мы дали ему доступ для выполнения его собственных снимков, а он попытается создать миллионы снимков "просто чтобы посмотреть что произойдёт". Вы знаете таких людей.

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

Чтобы держать в узде абсолютное зло, которым является Лукас, ограничьте число снимков, которое он сможет создавать, двумя.


# zfs set snapshot_limit=3 zroot/usr/home/lucas
# su lucas
$ zfs snapshot zroot/usr/home/lucas@three
$ zfs snapshot zroot/usr/home/lucas@four
cannot create snapshot ‘zroot/usr/home/lucas’: out of space
 	   

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

Предоставление полномочий и джейлы являются мощными инструментами для административного управления пространством хранения. Теперь давайте обсудим совместное использование данных в ZFS.