gdb игнорирует исполняемые возможности

Некоторое время назад я столкнулся с той же проблемой. Я предполагаю, что запуск отлаженной программы с дополнительными возможностями является проблемой безопасности.

Ваша программа имеет больше привилегий, чем пользователь, который ее запускает. С помощью отладчика пользователь может манипулировать выполнением программы. Таким образом, если программа запускается под отладчиком с дополнительными привилегиями, пользователь может использовать эти привилегии для других целей, отличных от тех, для которых программа намеревалась их использовать. Это было бы серьезной дырой в безопасности, потому что пользователь изначально не имеет привилегий.

Я столкнулся с той же проблемой, и вначале я подумал так же, как и выше, что, возможно, gdb игнорирует возможности исполняемого файла из соображений безопасности. Однако, читая исходный код и даже используя сам gdb для отладки eclipse, когда он отлаживает мою ext2fs-прогу, которая открывает /dev/sda1, я понимаю, что:

1. gdb ничем не отличается от любой другой программы. (Как и в матрице, даже сами агенты подчиняются одному и тому же физическому закону, гравитации и т. д., за исключением того, что все они привратники.)
2. gdb не является родительским процессом отлаживаемого исполняемого файла, вместо этого он является дедушкой.
3. Истинный родительский процесс отлаживаемого исполняемого файла - это «оболочка», то есть /bin/bash в моем случае.

Итак, решение очень простое, помимо добавления cap_net_admin,cap_net_raw+eip в gdb, вы также должны применить это к своей оболочке. то есть setcap cap_net_admin,cap_net_raw+eip /bin/bash

Причина, по которой вы также должны сделать это с gdb, заключается в том, что gdb является родительским процессом /bin/bash перед созданием отлаженного процесса.

Настоящая исполняемая командная строка внутри gdb выглядит следующим образом:

/bin/bash exec /my/executable/program/path

И это параметр для vfork внутри gdb.

Для тех, у кого такая же проблема, вы можете обойти ее, выполнив gdb с помощью sudo.

Для тех, кто запускает GDB через IDE, sudo-ing GDB (как в ответе @Stéphane J.) может оказаться невозможным. В этом случае вы можете запустить:

sudo gdbserver localhost:12345 /path/to/application

а затем подключите экземпляр GDB вашей IDE к этому (локальному) GDBServer.

В случае Eclipse CDT это означает создание новой конфигурации отладки «Удаленное приложение C/C++», затем на вкладке «Отладчик» > «Подключение» введите TCP/localhost/12345 (или любой другой порт, который вы выбрали выше). Это позволяет выполнять отладку в Eclipse, в то время как ваше приложение имеет привилегированный доступ.

Я использовал решение @NickHuang, пока одно из системных обновлений не сломало службы systemd (слишком много возможностей в bash, чтобы systemd мог запустить его или что-то в этом роде). Переключился на то, чтобы оставить bash в покое и вместо этого передать команду gdb для прямого вызова исполняемого файла. Команда

set startup-with-shell off

Хорошо, поэтому я немного боролся с этим, поэтому решил объединить ответы и подвести итоги.

Простое решение — просто sudo gdb, как было предложено, но будьте немного осторожны. Здесь вы запускаете отлаженную программу с правами root. Это вполне может привести к тому, что он будет работать иначе, чем когда вы запускаете его из командной строки в качестве обычного пользователя. Может быть немного запутанным. Не то чтобы я КОГДА-ЛИБО попал в эту ловушку... Упс.

Это нормально, если вы запускаете отлаживаемую программу от имени пользователя root с sudo ИЛИ если в отлаживаемой программе установлен бит setuid. Но если отлаживаемая программа работает с возможностями POSIX (setcap / getcap), то вам необходимо отразить эти более детализированные разрешения в bash и gdb, как предложил Ник Хуанг, а не просто перебирать разрешения с помощью «sudo».

Делая что-либо еще, вы можете оказаться в плохом месте экстремального обучения.