Linux программирование в примерах - Арнольд Роббинс

• Приложения, действующие как root, могут перманентно заменить значения действительного, эффективного и сохраненного ID с помощью setuid() и setgid(). Одним из таких примеров является login, которая должна превратиться из программы, выполняющейся как root в не непривилегированную зарегистрированную оболочку, выполняющуюся от имени обычного пользователя.

• Функции Linux setresuid() и setresgid() следует использовать всегда, когда они доступны, поскольку они обеспечивают самое чистое и наиболее надежное поведение

• Написание приложений setuid-root не является задачей для новичка. Если вам нужно сделать такую вещь, сначала специально изучите проблемы безопасности. Для этого можно воспользоваться приведенными выше превосходными источниками.

Упражнения

1. Напишите простую версию команды id. Ее назначением является отображение в стандартный вывод ID пользователя и группы с указанием имен групп. Когда эффективный и действительный ID различаются, выводятся оба. Например:

$ id

uid=2076(arnold) gid=42(devel) groups=19(floppy), 42(devel), 2076(arnold)

Ее использование:

id [ пользователь ]

id -G [ -nr ] [ пользователь ]

id -g [ -nr ] [ пользователь ]

id -u [ -nr ] [ пользователь ]

При указанном пользователе выводятся сведения об этом пользователе; в противном случае id выводит сведения о пользователе, вызвавшем программу. Опции следующие:

 -G  Выводит все значения групп в виде чисел, без имен.

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

 -g  Выводит лишь эффективный GID.

 -u  Выводит лишь эффективный UID.

2. Напишите простую программу с именем sume и установите setuid на себя. Она должна запрашивать пароль (см. getpass(3)), который в целях данного примера может быть жестко вшит в исходный код программы. Если лицо, запустившее программу, вводит пароль правильно, sume должна выполнить exec оболочки. Попросите другого пользователя помочь вам ее протестировать.

3. Как вы относитесь к тому, чтобы сделать sume доступной для ваших друзей? Для ваших приятелей студентов или сотрудников? Для каждого пользователя на вашей системе?

Глава 12 Общие библиотечные интерфейсы — часть 2

В главе 6, «Общие библиотечные интерфейсы — часть 1», был представлен первый набор API библиотеки общего пользования. В некотором смысле, эти API поддерживают работу с фундаментальными объектами, которыми управляют системы Linux и Unix: время дня, пользователи и группы для файлов, сортировка и поиск.

Данная глава более эклектична; функции API, рассмотренные здесь, не особо связаны друг с другом. Однако, все они полезны в повседневном программировании под Linux/Unix. Наше представление движется от простых, более общих функций API к более сложным и более специализированным.

12.1. Операторы проверки: assert()

Оператор проверки (assertion) является утверждением, которое вы делаете о состоянии своей программы в определенный момент времени ее исполнения. Использование операторов проверок для программирования было первоначально разработано Хоаром (C.A.R. Hoare)[121]. Общая идея является частью «верификации программы»: так же, как вы проектируете и разрабатываете программу, вы можете показать, что она правильна, делая тщательно аргументированные утверждения о проявлениях кода вашей программы. Часто такие утверждения делаются об инвариантах — фактах о состоянии программы, которые, как предполагается, остаются верными на протяжении исполнения куска программы.

Операторы проверки особенно полезны для описания двух разновидностей инвариантов: предусловий и постусловий: условий, которые должны быть истинными соответственно перед и после исполнения сегмента кода. Простым примером предусловий и постусловий является линейный поиск:

/* lsearch --- возвратить индекс с данным значением в массиве или -1,

   если не найдено */

int lsearch(int *array, size_t size, int value) {

 size_t i;

 /* предусловие: array != NULL */

 /* предусловие: size > 0 */

 for (i = 0; i < size; i++)

  if (array[i] == value)

   return i;

 /* постусловие: i == size */

 return -1;

}

Этот пример определяет условия, используя комментарии. Но не было бы лучше проверить условия с использованием кода? Это является задачей макроса assert():

#include <assert.h> /* ISO С */

void assert(/* скалярное выражение */);

Когда скалярное выражение ложно, макрос assert() выводит диагностическое сообщение и завершает программу (с помощью функции abort(); см. раздел 12.4 «Совершение самоубийства: abort()»). ch12-assert.c снова предоставляет функцию lsearch(), на этот раз с оператором проверки и функцией main():

1  /* ch12-assert.с --- демонстрация операторов проверки */

2

3  #include <stdio.h>

4  #include <assert.h>

5

6  /* lsearch --- возвращает индекс с данным значением в массиве или -1, если не найдено */

7

8  int lsearch(int *array, size_t size, int value)

9  {

10  size_t i;

11

12  assert(array != NULL);

13  assert(size > 0);

14  for (i = 0; i < size; i++)

15   if (array[i] == value)

16    return i;

17

18  assert(i == size);

19

20  return -1;

21 }

22

23 /* main --- проверить наши условия */

24

25 int main(void)

26 {

27 #define NELEMS 4

28  static int array[NELEMS] = { 1, 17, 42, 91 };

29  int index;

30

31  index = lsearch(array, NELEMS, 21);

32  assert(index == -1);

33

34  index = lsearch(array, NELEMS, 17);

35  assert(index == 1);

36

37  index = lsearch(NULL, NELEMS, 10); /* won't return */

38

39  printf("index = %dn", index);

40

41  return 0;

42 }

После компиляции и запуска оператор проверки в строке 12 «выстреливает»:

$ ch12-assert /* Запуск программы */

ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.

Aborted (core dumped)

Сообщение от assert() варьирует от системы к системе. Для GLIBC на GNU/Linux сообщение включает имя программы, имя файла с исходным кодом и номер строки, имя функции, а затем текст завершившегося неудачей условия. (В этом случае именованная константа NULL проявляется в виде своего макрорасширения '((void*)0)'.)

Сообщение 'Aborted (core dumped)' означает, что ch12-assert создала файл core; т.е. снимок адресного пространства процесса непосредственно перед его завершением.[122] Этот файл может быть использован впоследствии с отладчиком; см. раздел 15.3 «Основы GDB». Создание файла core является намеренным побочным результатом assert(); предполагается, что произошла решительная ошибка, и вы хотите исследовать процесс с помощью отладчика для ее определения.

Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '-DNDEBUG'. Когда этот макрос определен до включения <assert.h>, макрос assert() расширяется в код, который ничего не делает. Например:

$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */

$ ch12-assert /* Запуск */

Segmentation fault (core dumped) /* Что случилось? */

Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15 lsearch() при вызове из строки 37 main(). В этом случае переменная array равна NULL. Доступ к памяти через указатель NULL является ошибкой. (Технически различные стандарты оставляют «неопределенным» то, что происходит при разыменовывании указателя NULL. Наиболее современные системы делают то же, что и GNU/Linux; они завершают процесс, посылая ему сигнал SIGSEGV; это, в свою очередь, создает дамп ядра. Этот процесс описан в главе 10 «Сигналы».

Этот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест 'array != NULL' должен был быть проверкой времени исполнения:

if (array == NULL) return -1;

Тест 'size > 0' (строка 13) менее проблематичен; если size равен 0 или меньше 0, цикл никогда не исполнится, и lsearch() (правильно) возвратит -1. (По правде, этот оператор проверки не нужен, поскольку код правильно обрабатывает случай 'size <= 0'.)