Портирование под OpenBSD

Самое важное - не молчать. Спросите в конференции ports@openbsd.org, не ведется ли работа над этим портом. Напишите о создании порта автору программы, сообщите о проблемах, которые вам удалось найти. Если сведения о лицензии некорректны, сообщите ему об этом. Если для того, чтобы собрать порт, вам пришлось пройти огонь, воду и медные трубы, расскажите автору программы, что в ней нужно исправить. И, наконец, если автор программы пишет только под Linux и не думает, что пользователи других систем заслуживают внимания, постарайтесь переубедить его.

Прежде всего прочитайте информацию на этой странице. После этого обратитесь к смежным документам, в особенности к списку требований к портированным приложениям.

Наконец, проведите как можно более тщательное тестирование порта!

После этого порт можно отсылать. Запакуйте директорию, в которой хранятся файлы порта, tar-ом и gzip-ом. Выложите архив на FTP или веб-сервере и пошлите ссылку на него в конференцию ports@openbsd.org. Вы можете также послать в конференцию сам файл в кодировке MIME, если вам так удобнее.

Разделы документа

• Доступная информация по портированию
• Правила портирования на OpenBSD
• Рекомендации по безопасности
• Общие советы
• Другая полезная информация

Доступная информация по портированию

• Список требований к портированным приложениям.
• Страница руководства bsd.port.mk(5). Это документация по makefile из инфраструктуры портов. Он подключается в каждом отдельном порте. Работа над этим руководством все еще не завершена, но большинство полезной информации документирована.
• Отличия от других систем портов BSD, в основном, отличия в инфраструктуре.
• Использование разделяемых библиотек в портах OpenBSD. Описываемые в документе правила очень важны при использовании разделяемых библиотек, особенно с учетом появления в перспективе pkg_update.
• Портирование приложений для работы с аудио на OpenBSD.
• Документация по системе пакетов NetBSD. В этом весьма полезном документе описывается NetBSD-версия системы портов FreeBSD.
• Руководство по портированию приложений на FreeBSD. Это основной документ, используемый при переносе приложений на эту систему.
• Список рассылки ports@OpenBSD.ORG.

Правила портирования на OpenBSD

• В OpenBSD не используется подсистема /usr/local/etc/rc.d.
  /usr/local часто экспортируется по NFS и используется несколькими машинами. По этой причине конфигурационные файлы для каждой отдельной машины хранятся не в /usr/local, а в /etc. Еще одним правилом OpenBSD является то, что файлы в /etc никогда не обновляются автоматически. Если для порта требуется выполнение каких-либо действий при загрузке системы, то вместо автоматической правки файлов в /etc, администратору должны быть предоставлены сведения о том, что необходимо сделать.
• В OpenBSD не производится сжатие страниц руководства.
• В OpenBSD не требуется -lcrypt.
  Шифрование по алгоритму DES является частью стандартной библиотеки libc.
• В OpenBSD есть отдельное пространство имен для пользователей и групп, создаваемых портами. Посмотрите /usr/ports/infrastructure/db/user.list.
• В OpenBSD огромную роль играет безопасность. Внимательно прочтите раздел по безопасности на этой странице.
• Добавьте в Makefile CVS-тэг $OpenBSD$. Если программа портируется с другой системы, оставьте в Makefile тэг этой системы. Однако тэг $Id$ для FreeBSD должен быть заменен на $FreeBSD$.
• В идеале все портированные приложения должны поддерживать OpenBSD. Чтобы добиться этого, вам необходимо отправить все проделанные изменения лицу, занимающемуся поддержкой этой программы.

Рекомендации по безопасности

• Не используйте альфа- или бета-версию программы для портирования. Это должна быть последняя стабильная версия или версия с исправлениями (patch release).
• Приложения-сервера нужно тщательно проанализировать на предмет переполнения буфера. В особенности, на использование небезопасных функций strcat/strcpy/strcmp/sprintf. sprintf должен быть заменён на snprintf.
• Для обеспечения безопасности системы не используйте временные файлы с жестко заданными именами. Может получиться так, что вы не сможете контролировать их. Например, злоумышленник, имеющий пользовательский доступ в систему, может заменить файлы в каталоге /tmp символическими ссылками на более важные системные файлы, например, /etc/master.passwd.
• Например, fopen и freopen создают новый файл или открывают существующий файл для записи. Злоумышленник может создать символическую ссылку /tmp/addrpool_dump на файл /etc/master.passwd. Как только ссылка будет открыта, файл паролей будет поврежден. Даже если перед открытием вы вызовете функцию unlink, этим вы просто ограничите вероятность атаки. Вместо fopen и freopen рекомендуется использовать open с O_CREAT|O_EXCL и fdopen.
• Еще одна часто встречающаяся проблема заключается в использовании функции mktemp. Если линковщик bsd выдает предупреждения по поводу ее использования, внесите необходимые поправки в исходный код. Это не просто s/mktemp/mkstemp/g.
  Обратитесь к странице руководства mktemp(3) за более подробной информацией. Правильное использование mkstemp можно увидеть в исходном коде ed и mail. Редким случаем правильного использования mktemp является порт rsync.
• Факт наличия прав на чтение файла не означает то, что программа должна его читать. Известный случай уязвимости такого рода был в startx. Поскольку это была setuid-программа, то ее можно было запускать с любым файлом в роли скрипта. Если файл не был скриптом, выдавалось сообщение о синтаксической ошибке в выводилась первая строка этого файла без проверки прав доступа. Это позволяло, например, получить первую строку из файла паролей, который обычно начинается с записи root. Не следует также открывать файл, а затем смотреть с помощью fstat, возможно ли открытие (злоумышленник может воспользоваться этим, чтобы получить доступ к /dev/rst0 и перемотать ленту). Вместо этого, открывайте файл с заведомо правильными uid, gid и списком групп.
• Setuid-программы не должны порождать shell пока не сбросят привилегии. Это относится к popen и system. Вместо них используйте fork, pipe и execve.
• Передавайте внешним программам дескрипторы открытых файлов вместо имен во избежание race condition. Если программа не может принять файловый дескриптор, используйте их именной аналог, например /dev/fd/0.
• Права доступа передаются вместе с файловыми дескрипторами. Если вам необходимо использовать setuid для получения прав на открытие файла, откройте его, а затем сбросьте привилегии. Вы по-прежнему сможете обращаться к открытому файлу, однако, проблем, связанных с привилегиями, будет меньше. Но даже после сброса привилегий все равно следует внимательно следить за дескрипторами открытых файлов.
• Избегайте setuid для root. С правами root можно выполнять любые действия в системе, но эти привилегии требуются очень редко. Исключением, возможно, является создания сокета с номером порта меньше 1024. Вероятно лучшим решением будет передать это под управление inetd и просто добавить необходимые записи в inetd.conf. Для написания таких сервисов, необходимы специальные знания, а без них лучше и не пытаться писать setuid-программы.
• Используйте setgid вместо setuid. За исключением особых файлов, используемых setgid-программами, большинство файлов не доступны для записи группе. Поэтому уязвимость в setgid-программе не будет опасна для системы в целом. Самое худшее, что сможет сделать взломщик, это, например, изменить данные в файле с результатами игры и т.п.
• Не доверяйте файлам, доступным для записи группе. Несмотря на то, что setgid программы прошли аудит, они не рассматриваются как объекты повышенной опасности. Поэтому в данных, которыми они оперируют не должна содержаться важная информация.
• Не полагайтесь на переменные окружения! Это касается переменной PATH (не используйте system с неопределенным именем, избегайте использования execvp), а также более тонких вещей вроде локали, часового пояса, настроек терминала и так далее. Помните о том, что даже если вы приняли все меры предосторожности, программы которые вы вызываете - нет. Никогда не используйте system в привилегированных программах. Полностью создавайте строку исполнения программы, переменные окружения и только тогда вызывайте execve. Прочитайте страницу руководства perlsec, в котором хорошо освещен данный вопрос.
• Никогда не используйте setuid shell-скрипты. Они не безопасны. Запускайте их только внутри программы на C, которая обеспечит соответствующее окружение. Хотя, с другой стороны, в OpenBSD используются вполне безопасные скрипты на perl.
• Не забывайте о загрузчике динамических библиотек. Если вы работаете с setuid, то помните, что он использует только библиотеки, проверенные ldconfig. Использования setgid в данном случае недостаточно.
• Ряд сложностей возникает с динамическими библиотеками, а также с кодом на C++. Проблема заключается в том, что код этих библиотек, в зависимости от установленного окружения, может выполняться до того, как основная часть программы начнет проверять свой setuid статус. С точки зрения разработчиков библиотек этим вопросом в OpenBSD занимается issetugid. Мы не рекомендуем вам портировать библиотеки, если вы не полностью понимаете весь ход этого процесса.

Общие советы

• Ограничьте использование директивы __OpenBSD__ или вообще откажитесь от нее. Использование конструкции вроде

            #if defined(__NetBSD__) || defined(__FreeBSD__)
       

  редко уместно. Мы не советуем вам просто добавлять к этому списку __OpenBSD__. Вместо этого выясните, использование какой функциональности за этим стоит. Помощь в этом вам могут оказать страницы руководства, из которых можно узнать, когда та или иная функциональность была впервые введена в BSD. Обычно правильное решение - это сравнение переменной BSD с номерами релизов. За дополнительной информацией обратитесь к NetBSD package guide.
• Не определяйте сами параметр BSD. Вместо этого подключите sys/param.h. Это определит параметр BSD и присвоит ему верное значение. Фрагмент правильного кода:

           #if (defined(__unix__) || defined(unix)) && !defined(USG)
           #include <sys/param.h>
           #endif
       

• Тестируйте возможности, а не совместимость с операционными системами. В конце концов лучше выяснить, работает ли tcgetattr, чем определять выполняется ли программа под BSD 4.3 или SystemVR4. Тесты такого рода лишь вносят путаницу. Проведите тестирование под одной конкретной системой, установите значение HAVE_TCGETATTR, после чего переходите к другой системе. Бывает, что портирующий программу человек, чтобы сэкономить время, добавляет набор определений -DHAVE_XXX в Makefile. Или пишет конфигурационный скрипт, который проверяет наличие какой-либо функции и автоматически ее добавляет. Отрицательный пример - исходный код порта nethack 3.2.2, в котором очень много зависимостей от типа ОС. Большинство из них неактуальны: более удобно использовать POSIX функции, чем старые несовместимые функции BSD и SystemV. Тем более, что поддержка традиционных bsd функций сейчас осуществляется только через библиотеки совместимости.
• Избегайте использование include файлов, которые включают другие include файлы. Во-первых, это неэффективно. Ваш проект кончит тем, что будет включать файл который подключает все остальное. Это делает некоторые проблемы трудно разрешимыми. И в один прекрасный момент станет сложно убрать из включений определенный файл.
• Избегайте нестандартных операций с макросами. Не следует удалять макрос, определенный в заголовочном файле. Не следует также определять макрос для получения определенного поведения из include файла. Если необходимо соответствие с POSIX, определите #define POSIX_C_SOURCE для всего проекта, а не там где вы этого захотите.
• Не нужно писать прототипы системных функций. Во всех современных системах, включая OpenBSD, для них существует стандартное место. Например, файлы unistd.h, fcntl.h или termios.h. Об их местоположении написано на соответствующей странице руководства. Для включения нужного файла вам может понадобиться набор из макросов HAVE_XXX. Даже если файл будет включен дважды, ничего страшного не произойдет.
  Если для какой-то отдельной системы все таки необходимо написать прототип, не распространяйте это на все остальные системы. Такие прототипы могут привести к ошибке, поскольку в них могут использоваться типы данных которые не поддерживаются на других системах (например, unsigned long вместо size_t). К тому же, некоторые компиляторы, как gcc в OpenBSD, могут работать эффективнее с часто используемыми функциями, как strlen, если подключен правильный файл заголовка.
• Не используйте имена стандартных функций для ваших собственных. Присваивайте им уникальное имя. Если позже возникнет необходимость использовать стандартную системную функцию, вам потребуется лишь закомментировать ваш код и определить макрос указывающий на системную функцию. Ниже приведен фрагмент правильного кода:

         /* prototype part */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf);
         #else
         /* include correct file */
         #include <stdlib.h>
         /* use system function */
         #define foo_gcvt  gcvt
         #endif
  
         /* definition part */
         #ifdef USE_OWN_GCVT
         char *foo_gcvt(double number, size_t ndigit, char *buf)
            {
            /* proper definition */
            }
  
         /* typical use */
         s = foo_gcvt(n, 15, b);
         

Другая полезная информация

• Не следует создавать разделяемые библиотеки (shared libs) если определена переменная ${NO_SHARED_LIBS} (но будьте внимательны, она может быть определена только после включения bsd.port.mk). Если ваш порт использует GNU configure, добавьте строку CONFIGURE_ARGS += ${CONFIGURE_SHARED} в Makefile.
• Допускается использовать функции, появившиеся в последних версиях bsd.port.mk, поскольку предполагается, что пользователи должны обновлять все дерево портов, в том числе и bsd.port.mk. NEED_VERSION более не используется.
• В OpenBSD, curses.h/libcurses/libtermlib относятся к ``new curses''. Замените ncurses.h на curses.h. Чтобы использовать ``old (BSD) curses'', определите _USE_OLD_CURSES_ перед включением файла curses.h (обычно в Makefile) и делайте линковку с параметром -locurses.
• В OpenBSD организация терминала изменилась со старой BSD sgtty на новую tcgetattr семейства POSIX. Не рекомендуется использовать старую организацию в новых версиях программ. В некоторых случаях tcgetattr может определяться как синоним к sgtty, но в OpenBSD это может рассматриваться лишь в качестве временной меры. Отрицательным примером в данном случае может служить исходный код xterm. Правильно представьте функциональность системы: вам необходим тип данных, который запоминает состояние термианала (возможно typedef), необходима функция которая извлечет текущее состояние и функция которая установит новое состояние терминала. Функции, которые изменяют состояние более сложны, поскольку они различны в разных системах. Помните, что вам необходимо обработать случаи, при которых программа не соединена с терминалом; не забывайте и о сигналах, причем не только о сигнале завершения, но и о сигнале перевода процесса в фоновый режим (SIGTSTP). Программа должна возвращать терминал в нормальное состояние. Протестируйте свою программу под старой оболочкой, например sh, которая не возвращает терминал в исходное состояние.
• Новые версии termcap/terminfo и curses, из поставки OpenBSD, содержат стандартные процедуры управления цветными терминалами. По возможности рекомендуется пользоваться ими, на других системах используйте стандартные ANSI коды. Однако, описания некоторых терминалов еще не обновились, и вам, возможно, придется вводить эти коды вручную. По такому принципу работает vim. Но это не является обязательным. Кроме случаев с привилегированными программами, возможно изменить переменную TERMCAP для корректной работы.
• Семантика сигналов сложна и различна на разных системах. Обратитесь к странице руководства по sigaction за дополнительной информацией.