Странности в правах процессов

Где такая работа прав описана в документации по Linux?

В исходниках конкретного софта, а так же glibc.

Вообще не совсем понятно что именно ты хочешь получить, и главное - зачем. С тем же успехом можно пробовать отобрать у всех доступ на / и жаловаться, что «почему-то» ничего не работает.

Вообще не совсем понятно что именно ты хочешь получить, и главное - зачем.

Объясните мне, почему когда процесс запущен от Debian-exim:Debian-exim, то он не имеет доступа к дирректории к которой иметь доступ должен по причине того, что Debian-exim входит в группу, которая назначена этой дирректории? Ответте на такой простой вопрос.

Ответте на такой простой вопрос.

Вопрос на самом деле не простой. Потому что я не телепат и я не знаю, какие именно права на директории и файлы ты поставил, и как именно на это отреагировал exim.

$ ls -ld test
drwxr-x--- 2 root test 4096 июн 17 14:55 test

$ sudo -u Debian-exim ls test
ls: невозможно открыть каталог test: Отказано в доступе

$ sudo gpasswd -a Debian-exim test
Добавление пользователя Debian-exim в группу test

$ sudo -u Debian-exim ls test
hello

разбирайся, может что-то не так сделал. смотри strace'ом например за процессом exim'а.

ну про exim сложно рассказать, проще на примере sudo. Попробуй /etc отключить права для other. Потом под рутом попробуй sudo. Он скажет: unable to stat /etc/sudoers: Permission denied... Я искал методом перебора пользователя и группу с которыми sudo получит доступ к /etc. Оказалось что это daemon:plugdev. Далее я на /etc назначил группу daemon2, дал daemon2 все права на /etc и пользователя daemon добавил в группу daemon2. Что вы думаете, что sudo запустился? Нет. Он снова не получил доступа к /etc. Вот кое-что нашёл: http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=setgroups&category=2 Если я правильно понял, то в программе можно этим функциями отбрасывать дополнительные группы. Поправьте меня, если это не так.

разбирайся, может что-то не так сделал. смотри strace'ом например за процессом exim'а.

Так-то будет работать. Всё удивительное происходит в самом sudo, видимо в нём создаётся процесс с правами daemon:plugdev и этот процесс пытается прочитать настройки в /etc. То есть эту ситуацию в bash неимитировать, это надо на СИ писать тестовую прогу.

не понял откуда это всё.

вот, то что описано в ОП

# ls -ld /etc/
drwxr-xr-x 169 root root 12288 июн 17 15:06 /etc/

# chmod o-rx /etc/

# sudo ls /
bin   etc <...>

итого, при убирании прав для ohter на /etc, sudo не подает никаких признаков возмущения.

$ lsb_release -ds

Debian GNU/Linux unstable (sid)

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

вообще, опять же непонятно, что в этом странного - это наоборот, испокон веков так и очень даже естественно. куча юзеров и групп заводится пакетными менеджерами при установке некоторых прог, которым ничего не принадлежит и смысл существования которых как раз в этом. ясен пень, если ты закроешь доступ для other на тот же /etc то всё перестанет работать. представь себе даже твой браузер будет не рад. да и остальные программы, запущенные из-под юзера.

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

смотри strace'ом например за процессом exim'а.

Попробовал strace, к сожалению в нём недостаточно информации, либо я не умею читать его лог. Видно что sudo инициализирует sudoers подсистему, но потом сразу ошибка. От какого имя:группа он всё делает - не видно.

может дело в suid/sgid на sudo?

итого, при убирании прав для ohter на /etc, sudo не подает никаких признаков возмущения.

Надо для /etc изменить группу с root на любую другую, тогда будет сообщение.

может дело в suid/sgid на sudo?

По умолчанию suid включен, пробовал играться с suid/sgid - безрезультатно.

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

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

Программа sudo запускается от root, при этом дальше работает от daemon:plugdev и одновременно работает от дополнительных групп пользователя root, но при этом права самого пользователя root недоступны. По этому решение для sudo такое: добавить root в группу которая назначена на /etc, далее обязательно перезапустить всю сессию ssh, так-как даже после рестарта bash в groups группы не появляется. После перезапуска сессии sudo работает как надо - через группу daemon2.

решил закрыть доступ к /etc для other

зачем? делать нечего?

А sudo выполняется от root. man suid bit

А sudo выполняется от root. man suid bit

оказалось не всё так просто, это решено, теперь пытаюсь понять что нужно для exim4.

в слаке всё именно просто. Но часто есть ещё и PAM…

теперь пытаюсь понять что нужно для exim4.

для начала ему надо, что-бы одмин прекратил заниматься х-й. Каталог /etc/ должен иметь общий доступ на чтение для ВСЕЙ системы, ибо там хранятся ВСЕ настройки этой самой системы. То, что ты делаешь, напоминает ночной горшок с ручкой внутри.

два раза поржал, спасибо

так не честно: ты так и не сказал, зачем тебе запрещать доступ к /etc/ ?

Не хочу, чтобы юзеры видели настройки сервера.

Не хочу, чтобы юзеры видели настройки сервера.

ты делишь на ноль. Шелл должен их и видеть и не видеть одновременно. Не хочешь так? Тогда не давай шелл, или дай особый шелл (например апач выше докрута ничего не видит. Proftpd тоже можно так настроить, я так и делаю).

Впрочем, могу дать идею: запрети ЧТЕНИЕ каталогов. А секретный конфиг называй типа «471e997ce8c23ad558c2935b88814ab3». Тогда демон сможет увидеть и прочитать конфиг 471e997ce8c23ad558c2935b88814ab3, а вот юзер не сможет, ибо списка нет (права 0711).

Что я имею ввиду: например если от пользователя root выполнить sudo, то при закрытом доступе к /etc для other - комманда sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin Так вот если на /etc назначить пользователя daemon, то sudo выполнится без проблем, видимо внутри sudo происходит переключение на daemon. А теперь внимание: если на /etc назначить пользователя root и группу daemon2, далее пользователя daemon добавить в группу daemon2, то sudo сообщит: sudo: unable to stat /etc/sudoers: Permission denied ... То есть sudo без разницы в каких группах находится daemon, хоть в той, которая имеет доступ к /etc... То же самое происходит, если на /etc/ назначить группу daemon, при том, что пользователь daemon включён в группу daemon по умолчанию. Я обнаружил, что sudo выполняется от имени daemon и группы plugdev. Подозреваю, что из-за определения группы plugdev блокируются все другие группы.

Вопрос к знатокам этого форума: объясните что это всё такое?

слишком много свободного времени :-P

Да ты поэт!

Не хочу, чтобы юзеры видели настройки сервера.

Про chroot и контейнеры в ваших краях еще не слышали?

ночной горшок с ручкой на дне.

Просто из опыта администрирования тачек в датацентре - закручивание гаек клиентами в большинстве случаев приводило к реинсталлу.

Лучше ты определись что именно ты скрываешь (только не «хочу скрыть всё»). Возможно, твоя проблема может быть решена меньшей кровью. На крайняк разнеси клиентов по виртуалкам.

Просто из опыта администрирования тачек в датацентре - закручивание гаек клиентами в большинстве случаев приводило к реинсталлу.

правило 95%.

Сдается мне вам нужен MAC, а не те костыли, которые вы городите

что за правило 95%?

http://lurkmore.to/95%_населения_—_идиоты

слишком много свободного времени :-P

в точку. Время кончилось, по этому проблему законсервировал в состоянии когда чувствую что продвинулся на несколько шагов вперёд в знании линукса.

Сдается мне вам нужен MAC, а не те костыли, которые вы городите

крутая вещица, буду помнить

Итак, в чём я там продвинулся: запуская exim4 коммандой /sbin/start-stop-daemon --start --exec /usr/sbin/exim4 — -bd -d+all -q30m видно, как он легко меняет uid:gid процессов, при этом обнуляя auxiliary group list, то есть именно тот список, который я так упорно пытался настроить. Взглянув на конфигуратор исходников exim4 я нашёл целую кучу переменных отвечающих за то от какого uid:gid будут те или иные действия. Поразмыслив о том, что движение от дебиан сборки exim к кастомной сборке exim это движение вперёд, это прогресс, это возможности тонкой настройки - я решил собрать exim. За час собрал, но потом не смог его настроить так, чтобы он пересылал исходящую с него почту на внешний smtp. На этом и остановился. Проблему с правами считаю решёной - кроме всяких битов на исполняемые файлы, бывают ещё манипуляции в самом исполняемом файле, которые в полноте могут знать лишь линукс-программисты. Задачу сделать закрытой для юзеров /etc считаю выполнимой, просто для её завершения нужно намного больше времени, но сейчас в принципе всё бы было хорошо, если бы не exim4, задача то уже была вот-вот завершённая: mysql, apache, bind9, иксы и т.д. и т.п. уже работали при полностью закрытом /etc и ряде других системных дирректорий. Задачу законсервировал, /etc открытый, юзеры в песочнице, отложу решение до следующей встречи с проблемой. А сейчас и правда пора работать.

Задачу сделать закрытой для юзеров /etc считаю выполнимой

и как интересно тот же bash, запущенный от пользователя, будет читать /etc/passwd? это необходимо.