Отладка Setuid программы/«Доступ запрещен» с УИП

Question

Это фактически три части вопроса, которые я объясню ниже, но вопросы:

• Использование GDB, как я могу запустить часть программа с полномочиями root, а остальное с нормальным?
• Зачем мне «разрешено запрещать» с помощью mkstemp для создания файла в/tmp в программе setuid (to root)?
• Почему «sudo program_name» выполняет какие-либо разные действия только от ./program_name с помощью setuid для root?

У меня есть программа на C, работающая на Linux (несколько дистрибутивов), которая обычно запускается пользователем с нормальными привилегиями, но некоторые части программы должны работать с правами root. Для этого я использовал флаг set-UID, и это работает отлично, насколько это возможно.

Однако, теперь я хотел бы отлаживать программу с обычными полномочиями пользователей, и я считаю, что у меня есть catch-22. Я только что добавил функцию для создания временного файла (/ tmp/my_name-XXXXXX), и эта функция вызывается из многих точек внутри программы. По какой-то причине, эта функция выдает следующее сообщение при запуске:

sh: /tmp/my_name-hhnNuM: Permission denied 

(конечно, фактическое имя изменяется.) И все же, программа способна выполнять сырец функцию сокета, что я абсолютно не знаю, может быть сделано пользователей, отличных от root. (Если я удаляю флаг setuid, программа терпит неудачу.)

Если я запускаю эту программу через gdb без sudo, она умирает от сырых сокетов (поскольку gdb, по-видимому, не делает - или, вероятно, не может - почитать флаг setuid в программе). Если я запустил его под «sudo gdb», тогда все будет хорошо. Если я запускаю его как «SUDO ./my_name, все работает отлично

Вот низкоспиновое -l выход для этой программы:.

-rwsr-xr-x 1 root root 48222 Jun 23 08:14 my_name 

Так мои вопросы, в частности, нет порядка:

• (Как) могу ли я запускать разные части программы с различным эффективным UID под gdb?
• Почему «sudo ./program» отличается от «./program», когда ./program имеет set-uid для root?
• Почему mkstemp терпит неудачу при вызове обычного пользователя в программе setuid (to root)?

Answer 1

Единственный способ отладки Setuid приложения должным образом под GDB является отлаживать как корень. Самый разумный способ сделать это для приложения setuid - приложить к приложению после его запуска. Быстрый трюк, чтобы сделать это, чтобы добавить строку в УИП приложения:

kill(getpid(), SIGSTOP); 

Это заставляет его остановиться на этом этапе, а затем прикрепить GDB с помощью:

sudo gdb <application> <pid> 

Тогда вы привязаны к приложение и может отлаживать его как обычно.

sudo изменяет правила, так как позволяет экспортировать различные объекты из среды текущего пользователя в среду пользователя root. Это полностью зависит от текущей конфигурации sudo и может оставить вас в совершенно другой среде, чем приложение setuid, поэтому вам нужно полагаться на трюки, такие как остановка приложения и последующее подключение к нему во время выполнения.

Кроме того, в приложении может быть установлена ​​логика, чтобы определить, работает ли она в среде setuid, которая на самом деле не выполняется при запуске под sudo - помните, что sudo устанавливает все поля идентификатора процесса (real uid, эффективный uid и сохраненный uid) к тому же значению, которое не установлено setuid (реальный uid по-прежнему относится к исходному абоненту). Вы можете использовать вызов getresuid() для определения состояния трех переменных.

Дело в том, что сообщение Permission Denied имеет префикс sh:; это, по-видимому, подразумевает выполнение другого подпроцесса, который пытается получить доступ к файлу. После того, как вы вызвали mkstemp, вам может понадобиться освободить разрешение на чтение файла, чтобы подпроцесс смог прочитать файл.