[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Number of groups и замена GLIBC



В Втр, 11/10/2005 в 19:35 +0400, Alexey Lobanov пишет:
круто. только почему нельзя было заюзать debian-sources и собирать
нормальные дебиановские пакеты?
> 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.
> 
> А.Л.
> 
> 
> 
> 
-- 
Yury Luneff,
TSURE, 2005.            ICQ 293527227           JabberID bitterman@jabber.ttn.ru

Attachment: signature.asc
Description: =?iso-8859-5?Q?=CD=E2=D0?= =?iso-8859-5?Q?_=E7=D0=E1=E2=EC?= =?iso-8859-5?Q?_=E1=DE=DE=D1=E9=D5=DD=D8=EF?= =?iso-8859-5?Q?_=DF=DE=D4=DF=D8=E1=D0=DD=D0?= =?iso-8859-5?Q?_=E6=D8=E4=E0=DE=D2=DE=D9?= =?iso-8859-5?Q?_=DF=DE=D4=DF=D8=E1=EC=EE?=


Reply to: