Я заметил, что некоторые из моих пользователей не получили coredump вообще после сбоя, даже если все остальное в их конфигурации показалось правильным.
После прочтения core (5) man-страницы несколько раз я заметил эту конкретную точку:
[Файл дампа ядра не создается, если] Процесс выполняет программу set-user-ID (set-group-ID), которая принадлежит пользователю (группе), отличному от реального пользователя (группы) ID процесс.
Мой демон не установлен root, но во множестве конфигураций он запускается с правами root, а если файл .conf указывает имя пользователя, он оставляет привилегии с обычной комбинацией:
setgid(gid);
setuid(uid);
Когда это произойдет, coredumps больше не создаются. Все остальное в окружающей среде кажется правильным, удаляя эти вызовы (и сохраняя их как root), как обычно, получает ядро.
Я попытался изменить "реальный" uid/gid, как подсказывал справочная страница, вызвав менее портативный setresgid/uid, который, как представляется, часто предлагает отказаться от привилегий навсегда:
setresgid(gid, gid, gid);
setresuid(uid, uid, uid);
Я ожидал, что решить проблему, но... она вообще не улучшилась. Тем не менее никаких выпуклых выпусков.
Sooo... теперь что?
Тестовый код:
#include <stdlib.h>
int main(int argc, char **argv) {
if (argc > 1) {
setgid(atoi(argv[2]));
setuid(atoi(argv[1]));
}
abort();
}
Использование:
-
./a.out
, поскольку любой пользователь просто отменяет без setgid/setuid -
./a.out 1000 100
(где 1000 - это uid, а 100 - gid), поскольку root имеет привилегии для сброса, а часовые выходы не происходят. - Бонусная непреднамеренная функция: передать один параметр, а не два, чтобы получить SIGSEGV вместо SIGABRT.
Я уже тестировал это в arch linux, centos 6.5 и openbsd 5.3