Number of groups и замена GLIBC
Hi all.
По итогам свежих действий, с претензией на faq.
Во всех Юниксах традиционно существует жесткое ограничение на количество
групп, к которым может принадлежать пользователь. Более того, это
ограничение забито в RFC для NFS. Однако в корпоративной среде может
реально возникать возникать значительно большее количество "проектов" и
"рабочих групп", причём пользователь одновременно участвует во многих
проектах. ACL "per user" позволяет раздать права на объекты однократно
независимо от NGROUPS_MAX, но задача перевода юзера из одного проекта в
другой становится после этого весьма трудоёмкой.
В общем, хочется избавится от ограничения.
Значение ограничения в ядре записано у нас в /usr/include/linux/limits.h
#define NGROUPS_MAX 32 /* supplemental group IDs are available */
Помимо ядра это ограничение эффективно работает в главной системной
библиотеке, libc. При изменении значения в limits.h нужно пересобрать не
только ядро, но и libc.
Начиная с ядра 2.6.4 значение NGROUPS_MAX увеличено до 65536. Но libc
(aka glibc2) в стабильном дистрибутиве Дебиана собиралась на машине с
инклудами ядра 2.6.0; увидеть это можно запустив /lib/libc.so.6 как
программу.
aal@fs:~$ /lib/libc.so.6
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-12).
Compiled on a Linux 2.6.0-test7 system on 2005-05-10.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
Соответственно, далее есть два пути: собирать glibc из исходников самого
Дебиана или взять более свежую версию из первоисточника gnu.org.
По моему опыту: если мы вынуждены использовать свою версию какой-то
софтины вместо выдаваемой в составе системы, то нужно использовать ту
версию, которую рекомендуют разработчики софтины. Тогда дольше можно
будет ничего не трогать :-). В данном случае (по состоянию на
04-oct-2005) Дебиан использует glibc 2.3.2, разработчики дают 2.3.5.
Сборка:
cd /usr/src
mkgir glibc
cd glibc
../glibc-2.3.5/configure --enable-add-ons --prefix=/usr
make
Инсталляция: make install под конец работы надёжно убивает систему :-).
Невозможно запустить ни одну программу кроме статически линкованных.
Кстати, у вас ведь поставлен уже какой-нибудь статический шелл для
моментального восстановления при такой аварии, правда?
Суть беды в следующем. Debian имеет целое дерево версий glibc и
динамического загрузчика, оптимизированных под разные типы процессоров:
в /lib/, /lib/tls/, /lib/tls/i686.cmov/. Makefile знает только про
каноническое место /lib. И в какой-то момент замены возникает конфликт
версий между новым загрузчиком и этими дополнительными копиями
библиотек. Для безопасной инсталляции достаточно удалить всю ветку
/lib/tls/: после этого все вновь стартующие программы гарантированно
используют "каноническую" /lib/libc.so.6, а "make install" умеет
подменять её на ходу синхронно с загрузчиком, безопасным образом.
Результат в шелле немедленный:
root@fileserver:/usr/src/glibc# su -p myst
myst@fileserver:/usr/src/glibc$ groups|wc -w
37
Если вся операция делалась ради доступа из Самбы, то, естественно, надо
сказать /etc/init.d/samba restart.
NB: после замены libc на собранную таким простейшим образом система не
будет стартовать на старом (ниже i686) процессоре. Поскольку configure
оптимизирует код именно под имеющийся процессор: cmov и т.п. Параноики,
желающие полной переносимости, могут читать дальше INSTALL от glibc.
А.Л.
Reply to: