[devel] captive packaging issues

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

В общем, я собрал captive
(http://www.jankratochvil.net/project/captive/) в пакет. Сейчас еще
проверю его сборку в хэшере.

Перед заливкой мне хотелось бы уточнить несколько следующих моментов
(и внести требуемые изменения)

1. Удаление временных файлов

В оригинальном спеке в этом месте стоит удаление из captive'ской
песочницы (в /var/lib/captive) скопившихся там временных (но не убитых
по тем или иным причинам) файлов. %__rm -rf %_var/lib/captive/tmp/*.
Возникает вопрос: а стоит ли так делать, не обидятся ли на нас
пользователи.

2. Настройка captive

В оригинальном спеке при инсталляции пакета captive-install (с
конфигурационными утилитами) эти утилиты запускаются
(в неинтерактивном режиме, насколько я понимаю, хотя это еще проверять надо),
которые, во-первых, выискивают по диску требуемые виндовые потроха
(через ntfsprogs и собственные наработки) и модифицируют /etc/fstab,
включая (и удаляя на uninstall) строчку монтирования соответствующего
раздела.

У меня возникают сомнения в целесообразности подобной автоматики. Хотя,
надо признать, довольно удобно, по крайней мере, пока работает ;-)

3. suid-root демон

captive-sandbox-server сейчас является (один из вариантов для control)
suid-root из-за необходимости делать chroot в песочницу /var/lib/captive.
Мне кажется, это неправильно, и в этом месте можно пакет и доработать.
В данный момент я общаюсь с автором captive, и, наверное, эти изменения
можно будет пропихнуть в upstream. Вопрос заключается, во-первых, в том,
есть ли какие-нибудь уже готовые решения для разделения подобного рода
демона на chroot'ящуюся [suid-root] утилиту и собственно,
функционального демона. Во-вторых, хотелось бы знать, что у нас на
данный момент с использованием capabilities?


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]