Содержание


Принудительное применение ограничений среды

Ограничения для пользователей

Comments

В данной статье рассматриваются следующие темы.

  • Какие ограничения ресурсов следует накладывать в разных средах
  • Распространенные атрибуты ulimit
  • Ограничение оболочки
  • Дисковые квоты

Какие ограничения ресурсов следует накладывать?

При принятии решения об ограничениях для какого-либо пользователя следует проанализировать тип его учетной записи и понять, для чего используется эта учетная запись. Например, если это учетная запись владельца приложения, то серьезное внимание необходимо уделить увеличению некоторых настроек ulimit, поскольку в противном случае вы будете получать сообщения об ошибках по причине недостаточного количества открытых файлов или неспособности записать большие объемы данных на диск. Весьма распространенным явлением в последние несколько лет стало исчерпание ресурсов памяти. Так, регулярно возникает необходимость увеличения выделяемой физической памяти, поскольку в ulimit был задан низкий уровень соответствующих ограничений. Если учетная запись связана с поддержкой стороннего пользователя, который желает лишь просматривать файлы журналов, то администратору следует смотреть не на ulimit-ресурсы для этого пользователя, а заниматься ограничением его перемещения по своей системе. Я рекомендую в этом случае применять ограниченную оболочку или chroot-среду с использованием SFTP (Secure File Transfer Protocol) или FTP (File Transfer Protocol). Если учетная запись пользователя соответствует сотруднику внутренней службы поддержки, то надо иметь в виду, что все такие сотрудники стремятся убедить вас в том, что им требуются неограниченные ресурсы для поддержки своих приложений. Естественно, в первую очередь для этих типов пользователей следует рассмотреть возможность увеличения ограничивающих значений для размеров дампов ядра и размеров файлов.

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

Какие значения ulimit следует задавать?

Просмотрите запись (stanza) с ограничениями по умолчанию в каталоге /etc/security/limits. Это настройки по умолчанию, которые будет использовать пользовательская учетная запись. Однако эти значения можно переопределить, указав иные значения ulimit на уровне отдельного пользователя. Если любое значение по умолчанию будет переопределено для какого-либо пользователя, то у каждого пользователя будет отдельная stanza-запись. Эти значения ulimit можно изменить в инструменте SMIT (System Management Interface Tool) или с помощью команды chuser, или в ручном режиме посредством редактирования файла с ограничениями. Существует два типа значений ulimit: soft и hard. Soft-значения отображаются с помощью команды ulimit –a. Эти значения могут быть изменены пользователем; однако должен быть установлен предел того, насколько пользователь может увеличить свои значения ulimit. Именно для этого и применяются hard-значения. Обычный пользователь не может превысить hard-значение ограничения; изменить их может только пользователь root. Чтобы предоставить пользователю неограниченные значения ulimit, пользователь root указывает новые значения в виде "-1".

Чтобы увидеть soft-значения ulimit, воспользуйтесь командой: ulimit –a

Чтобы увидеть hard-значения ulimit, воспользуйтесь командой: ulimit -H

Теперь я продемонстрирую, как значения ulimit влияют на возможности обработки, предоставляемые нормальному пользователю. Ниже показано soft-значение ограничения для файлов пользователя. Обратите внимание, что fsize — это максимальный размер всех данных, которые пользователь может записать в файл. В следующем примере для fsize в настоящее время установлено значение 2097151 блоков по 512 КБ, что приблизительно составляет 1 ГБ.

$ ulimit -f
2097151

Если теперь пользователь попытается создать файл размером 900 МБ, то все должно быть прекрасно, поскольку ulimit-значение fsize для этого пользователя позволяет сделать это.

$ dd if=/dev/zero of=filename bs=1 count=0 seek=900M
0+0 records in.
0+0 records out.

Однако если он попытается создать файл размером 2 ГБ, то эта попытка будет отвергнута.

$ dd if=/dev/zero of=filename2 bs=1 count=0 seek=2G
dd: filename2: A file cannot be larger than the value set by ulimit.
dd: filename2: A file cannot be larger than the value set by ulimit.

Если присвоить fsize значение в районе 3 ГБ, то пользователь сможет успешно сгенерировать вышеупомянутый файл объемом 2 ГБ.

# chuser fsize=6291453 dxtans
$ ulimit -f
unlimited

В вышеупомянутом примере обратите внимание на следующий момент: я не пошел по легкому пути и не присвоил fsize неограниченное значение (-1); вместо этого я присвоил fsize благоразумное значение, которое требовалось для выполнения обработки.

$ dd if=/dev/zero of=filename2 bs=1 count=0 seek=2G
0+0 records in.
0+0 records out.

Конечно, все это прекрасно, если пользователь имеет возможность просмотреть конкретную настройку ulimit, однако рассмотрим ситуацию, когда учетная запись связана с приложением, которое не работает вследствие каких-либо проблем с ulimit. Как узнать о значениях ulimit для исполняющегося процесса? На данный момент не существует никакого "чистого" способа сделать это; единственное, что я припоминаю — это использование утилиты dbx (отладчик файлов исходного кода). К сожалению, у этого подхода имеется побочный эффект в виде уничтожения процесса после того, как вы выйдете из dbx. Сначала получите идентификационный номер (PID) нужного процесса, а затем с помощью утилиты dbx опросите этот процесс командой proc limit.

# ps -ef |grep collector
  dxtans 2961626 2941074   0 13:04:07  pts/0  0:00 collector
  
# dbx -a 2961626
Waiting to attach to process 2961626 ...
Successfully attached to collector.
warning: Directory containing collector could not be determined.
Apply 'use' command to initialize source path.

Type 'help' for help.
reading symbolic information ...warning: no source compiled with -g

stopped in read at 0xd0398168
0xd0398168 (read+0x1a8) 80410014         lwz   r2,0x14(r1)
(dbx) proc rlimit
rlimit name:          rlimit_cur               rlimit_max       (units)
 RLIMIT_CPU:         (unlimited)             (unlimited)        sec
 RLIMIT_FSIZE:       (unlimited)             (unlimited)        bytes
 RLIMIT_DATA:          134217728             (unlimited)        bytes
 RLIMIT_STACK:          33554432             (unlimited)        bytes
 RLIMIT_CORE:        (unlimited)             (unlimited)        bytes
 RLIMIT_RSS:            33554432             (unlimited)        bytes
 RLIMIT_AS:          (unlimited)             (unlimited)        bytes
 RLIMIT_NOFILE:            65535             (unlimited)        descriptors
(dbx) quit

В показанной выше выходной информации можно увидеть текущие значения ulimit для исполняющегося процесса. Однако после выхода из dbx этот процесс будет уничтожен. Конечно, прежде чем выйти из dbx, вы можете сначала корректно остановить этот процесс.

Ограничивающая оболочка и FTP

Если необходимо реализовать среду оболочки с более жесткими ограничениями, то одна из имеющихся возможностей состоит в том, чтобы реализовать т.н. ограниченную оболочку. Это достаточно просто, не правда ли? Выберите ограниченную оболочку, которую вы хотите использовать, для чего обеспечьте ее наличие в каталоге /etc/security/login.cfg. Затем командой chuser измените учетную запись пользователя, предоставив ему лишь соответствующую ограниченную оболочку. Теперь возможности этого пользователя ограничены. Этот подход будет работать лишь с новичком, но не с опытным пользователем. Такому пользователю достаточно ввести с клавиатуры другую bash-команду (в предположении, что соответствующая оболочка установлена в системе), после чего этот он больше не будет испытывать ограничений. Чтобы полностью погрузить пользователя в среду ограниченной оболочки, укажите в переменной PATH этого пользователя каталог BIN, расположенный за границами каталога HOME этого пользователя. В этом каталоге BIN должны присутствовать ссылки только на те команды, которые разрешено выполнять данной учетной записи. Это единственный надежный способ заблокировать пользователя в ограниченной оболочке. Применение chroot с использованием FTP упрощается благодаря файлу IBM® AIX® /etc/ftpaccess.ctl. Сначала создайте соответствующего пользователя, а затем присвойте ему атрибут puseronly в каталоге /etc/ftpaccess.ctl с использованием следующего формата. Это изменение является динамическим, пользователь сможет осуществлять изменения из своего каталога HOME.

psuseronly:<user_name>

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

Принудительное применение дисковых квот

Один из разумных методов управления использованием дискового пространства состоит в применении дисковых квот на основе ограничивающих параметров, устанавливаемых администратором. Это распространенный метод управления дисковым пространством, доступным пользователю. В моей ИТ-среде имеется множество машин и масса разработчиков. Если бы я не осуществлял принудительного применения квот, файловая система HOME на этих хостах разработки большую часть времени была бы заполнена. Учитывая, сколько раз приходится встречать разработчиков, пытающихся прятать дампы базы данных в своем каталоге HOME, складывается впечатление, что это нормальная практика. С точки зрения технического обслуживания я также считаю уместным применение дисковых квот для журнальных каталогов, используемых разработчиками – главным образом потому, что это второе по распространенности место в системе, в котором разработчик пытается сохранять файлы, когда собирается превысить предельные квоты в своем каталоге HOME.

Заключение

Принудительное применение ограничений на процессы и на среду помогает свести к минимуму работу администратора по наведению порядка (иного пути попросту нет). Кроме того, это хороший стандарт для машин разработки, поскольку это уменьшает объем работы администратора по удалению файлов.

Resources


Ресурсы для скачивания


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=983385
ArticleTitle=Принудительное применение ограничений среды
publish-date=09152014