SETUID / SETGID для двоичного исполняемого файла перестали работать после обновления Fedora Core

У меня есть программа на C, которая нуждается в полном доступе к защищенному каталогу.сильный текст Идея состоит в том, что только программа или администратор имеют доступ.

В прошлом на платформах Linux я довольно успешно использовал биты SETUID и SETGID файловой системы. Программа работает очень хорошо, так как, независимо от того, какой UID и GID указан в файловой системе, он является владельцем исполняемого файла независимо от того, кто его запускает.

Вернее, раньше он успешно работал.

Я не знаю точно, когда произошло это изменение, потому что я склонен обновлять ОС только в случае аппаратного сбоя, поэтому я получаю оба обновления сразу... Итак, если пропущено много версий, я, по праву, только это теперь система разработки на Fedora Core 17 больше не учитывает эти биты. Поскольку FC 19 является текущей версией, я думаю, что с последней версией дела обстоят только хуже, а не лучше.

Вот вывод 'ls -l':

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

При поиске решения я обнаружил, что страница руководства chmod гласит:

Дополнительные ограничения могут привести к игнорированию битов set-user-ID и set-group-ID в MODE или RFILE. Это поведение зависит от политики и функциональности основного системного вызова chmod. В случае сомнений проверьте поведение системы.

ОК, но у меня НЕТ ИДЕИ, как проверить эту политику и функциональность в соответствии с предложением! Они не предложили никакой помощи, кроме как использовать команду info - но я не нашел там ничего полезного, только данные о пользователе по умолчанию и принадлежности группы для создания нового файла.

SELINUX выключен.

Вопросы:

  1. Каков "правильный" способ сделать подобные вещи в современную эпоху?

  2. Как я могу проверить политики - и изменить их?

Спасибо за любой вклад.

БОЛЬШЕ ДАННЫХ:

Программа на C просто имеет следующую ветвь, чтобы вывести ошибку - отрывок:

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");

1 ответ

Решение

Проблема в вашем случае заключается в использовании access(),

man 2 access Страница говорит:

  The check is done using the calling process's real UID and GID,  rather
  than the effective IDs as is done when actually attempting an operation
  (e.g., open(2)) on the file.  This allows set-user-ID programs to  eas‐
  ily determine the invoking user's authority.

Когда вы работаете с двоичными файлами setuid, вы меняете только свой действующий UID, а не реальный. Итак access() звонок всегда будет неудачным.

Вы должны удалить access(), Это избыточно в этом случае, так как вы в любом случае используете fopen, чтобы открыть файл, также нужно выполнить такую ​​проверку доступа, а затем выполнить чтение.

Другие вопросы по тегам