[devel] captive packaging issues

[devel] captive packaging issues

[Alexey Morozov]

[-- 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 --]

[devel] Re: captive packaging issues

[Michael Shigorin]

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

On Thu, Feb 19, 2004 at 08:43:16PM +0600, Alexey Morozov wrote:
> %__rm -rf %_var/lib/captive/tmp/*.  Возникает вопрос: а стоит
> ли так делать, не обидятся ли на нас пользователи.

А это "известное оным" место?

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

Ну если это обвязка _отдельного_ пакета -- то почему нет?

IMHO если какое-то действие является:

- недеструктивным в разумно ожидаемой мере
- практически 100% выполняемым после установки пакета
- скриптуемым в неинтерактивном виде

-- то это повод об[в]язать его исполнением пакет.

> 3. suid-root демон
> captive-sandbox-server сейчас является (один из вариантов для control)
> suid-root из-за необходимости делать chroot в песочницу /var/lib/captive.
> Мне кажется, это неправильно, и в этом месте можно пакет и доработать.

chrootuid?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: captive packaging issues

[Alexey Morozov]

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

On Fri, Feb 20, 2004 at 10:16:09AM +0200, Michael Shigorin wrote:
> On Thu, Feb 19, 2004 at 08:43:16PM +0600, Alexey Morozov wrote:
> > %__rm -rf %_var/lib/captive/tmp/*.  Возникает вопрос: а стоит
> > ли так делать, не обидятся ли на нас пользователи.
> А это "известное оным" место?
Вероятнее всего, нет, т.к. это именно песочница, в которой играется
драйвер. У меня после нескольких [штатных] запусков там все пусто.

> Ну если это обвязка _отдельного_ пакета -- то почему нет?
> 
> IMHO если какое-то действие является:
> 
> - недеструктивным в разумно ожидаемой мере
> - практически 100% выполняемым после установки пакета
> - скриптуемым в неинтерактивном виде
> 
> -- то это повод об[в]язать его исполнением пакет.
Ну, хорошо. Я погоняю еще в разных странных режимах, чтобы убедиться,
что действительно неинтерактивно все работает.
> 
> > 3. suid-root демон
> > captive-sandbox-server сейчас является (один из вариантов для control)
> > suid-root из-за необходимости делать chroot в песочницу /var/lib/captive.
> > Мне кажется, это неправильно, и в этом месте можно пакет и доработать.
> chrootuid?
Э-э-э, не. chrootuid - не suid-root (и не должен). Должна же быть штука,
которая, будучи запущенной пользователем (если он имеет на это право),
сделает chroot в песочницу. Есть два варианта это сделать: fine-grained
capabilities (но как их по-настоящему использовать в нынешнем линуксе я
не знаю), и банальный suid-root, который чрутился бы, а потом делал бы
сброс прав.

Впрочем, сегодня обнаружилась доп. проблемка. Соответствующий маунт
принимает во внимание только установки локали, и игнорирует
iocharset=... Поэтому есть особенность: при запуске

sudo mount -t captive-ntfs ...

имена отображаются "правильно" (в KOI8-R), а при "системном" монтировании
- в UTF-8. Сегодня напишу Яну (Jan), посмотр[им], как можно поправить
быстро и правильно.


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

[devel] Re: captive packaging issues

[Michael Shigorin]

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

On Fri, Feb 20, 2004 at 03:28:46PM +0600, Alexey Morozov wrote:
> > > Мне кажется, это неправильно, и в этом месте можно пакет и
> > chrootuid?
> Э-э-э, не. chrootuid - не suid-root (и не должен). Должна же
> быть штука, которая, будучи запущенной пользователем (если он
> имеет на это право), сделает chroot в песочницу.

А.  Тогда получается еще helper?

> Есть два варианта это сделать: fine-grained capabilities (но
> как их по-настоящему использовать в нынешнем линуксе я не
> знаю)

Как-то задавал вопрос, так и не получил (положительного, по
крайней мере) ответа по части того, как это отрабатывать --
setpcaps в %post? -- и что с бэкапом/восстановлением (и просто
обновлением).

> и банальный suid-root, который чрутился бы, а потом делал бы
> сброс прав.

...т.е. нечто рутеющее и пинающее chrootuid. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] Re: captive packaging issues

[Alexey Morozov]

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

On Fri, Feb 20, 2004 at 12:22:49PM +0200, Michael Shigorin wrote:
> > Э-э-э, не. chrootuid - не suid-root (и не должен). Должна же
> > быть штука, которая, будучи запущенной пользователем (если он
> > имеет на это право), сделает chroot в песочницу.
> А.  Тогда получается еще helper?
A sort of.

> Как-то задавал вопрос, так и не получил (положительного, по
> крайней мере) ответа по части того, как это отрабатывать --
> setpcaps в %post? -- и что с бэкапом/восстановлением (и просто
> обновлением).
Ух ты. А оно работает? А на каких файловых системах? В смысле, как
хранится?

> > и банальный suid-root, который чрутился бы, а потом делал бы
> > сброс прав.
> ...т.е. нечто рутеющее и пинающее chrootuid. :)
Ну, как вариант. На самом деле, там всё чуть сложнее в связи с
необходимостью выполнения некоторых операций, помимо, собственно,
chroot'а.

В общем, я посмотрю еще...


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

Re: [devel] captive packaging issues

[Dmitry V. Levin]

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

On Thu, Feb 19, 2004 at 08:43:16PM +0600, Alexey Morozov wrote:
[...]
> 3. suid-root демон

suid-root или daemon?

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

Если daemon, то зачем suid-root?
Если suid-root, то зачем daemon?

> Во-вторых, хотелось бы знать, что у нас на
> данный момент с использованием capabilities?

$ aptbox/apt-cache showpkg libcap.so.1
Package: libcap.so.1
Versions: 

Reverse Depends: 
  zsh,libcap.so.1
  vsftpd,libcap.so.1
  traceroute,libcap.so.1
  tcptraceroute,libcap.so.1
  slocate,libcap.so.1
  pinentry,libcap.so.1
  osec,libcap.so.1
  ntpdate,libcap.so.1
  ntpd,libcap.so.1
  ntp-utils,libcap.so.1
  nmap,libcap.so.1
  libcap-utils,libcap.so.1
  jackd,libcap.so.1
  iputils,libcap.so.1
  givertcap,libcap.so.1
  coldsync,libcap.so.1
  aseqview,libcap.so.1
Dependencies: 
Provides: 
Reverse Provides: 
libcap 1:1.10-alt10


-- 
ldv

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

Re: [devel] captive packaging issues

[Alexey Morozov]

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

On Fri, Feb 20, 2004 at 01:47:13PM +0300, Dmitry V. Levin wrote:
> On Thu, Feb 19, 2004 at 08:43:16PM +0600, Alexey Morozov wrote:
> > 3. suid-root демон
> suid-root или daemon?
/usr/sbin/captive-sandbox-server, который будучи suid-root, обслуживает
в chroot'е запросы на доступ к FS.

> > можно будет пропихнуть в upstream. Вопрос заключается, во-первых, в том,
> > есть ли какие-нибудь уже готовые решения для разделения подобного рода
> > демона на chroot'ящуюся [suid-root] утилиту и собственно,
> > функционального демона.
> Если daemon, то зачем suid-root?
> Если suid-root, то зачем daemon?
Это зависит от смысла, вкладываемого в слово "демон". ssh-agent - демон?
Или просто "программа, запущенная все время жизни пользовательской
сессии"?

У captive есть несколько режимов функционирования. Один из них
предполагает прописывание соответствующей строчки в /etc/fstab, и,
понятное дело, никаких специальных прав на соответствующий файл давать
не нужно. Другой - доступ из cmdline. Третий - из gnome-vfs. Во всех случаях
разборки с собственно MS'овскими драйверами проистекают не напрямую, а через
прокладки в песочнице. Для организации песочницы в первом и втором
случаях требуется chroot для программы, запущенной пользователем

(вопросы раздачи прав на запуск через control я здесь опускаю)


> $ aptbox/apt-cache showpkg libcap.so.1
> Package: libcap.so.1
> Versions:
Как ей _реально_ пользоваться? Где и как сохраняется информация о том,
что данный процесс, запущенный, грубо говоря, с euid > 500, имеет право
сделать chroot? Есть ли внятные доки на этот повод?


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