[devel] libguestfs

[devel] libguestfs

[Alexey Shabalin]

Вечер добрый.
Опишу прогресс над адаптацией libguestfs для ALTLinux.
И прошу знатоков подсказать где я могу ошибаться.

В двух словах, как работают утилиты из состава libguestfs.
Для работы утилит, запускается виртуальная машина с помощью qemu, в
параметрах которой указывается ядро и образ initrd, внутри которого
установлена минимальная система и утилиты для работы с файловыми
системами (fsck.*, resizefs и т.п.). Внутри этой виртуалки также
запускается демон guestfsd который принимает указания снаружи от
утилит и выполняет необходимые действия.
Основная проблема - подготовить этот самый initrd (appliance).
В fedora для изготовления appliance используется проект supermin
(бывший febootstrap). В принципе я адаптировал supermin для работы с
apt-rpm, но решил отказаться от этого. Мне больше понравился подход
opensuse, где initrd (appliance) генерируется с помощью
mkinitrd(правда модифицированных).

Что сделано:
- используется make-initrd из master
git://git.altlinux.org/people/legion/packages/make-initrd.git
- для нового  make-initrd также нужен и новый sysvinit-initramfs из
master git://git.altlinux.org/people/legion/packages/sysvinit.git

- копируем текущее ядро в /usr/lib64/guestfs/vmlinuz.x86_64
- chmod 644 /usr/lib64/guestfs/vmlinuz.x86_64
- изготавливаем initrd:
   в /etc/initrd.mk.d/guestfs.mk
--------
IMAGEFILE = /usr/$(LIBNAME)/guestfs/initramfs.$(ARCH).img
FEATURES += guestfs
--------

  в /usr/share/make-initrd/features/guestfs/config.mk
--------
DISABLE_FEATURES += plymouth
FEATURES += devmapper qemu # в дальнейшем также понадобятся mdadm lvm btrfs
GUESTFS_DATADIR = \
        $(FEATURESDIR)/guestfs/data


GUESTFS_FILES   = \
        /usr/sbin/guestfsd \
        /usr/sbin/parted \
        $(wildcard /sbin/mount*) \
        $(wildcard /sbin/fsck*) \
        $(wildcard /sbin/mkfs*) \
        $(wildcard /sbin/*resize*) \
        $(wildcard /sbin/*disk)
--------

  в /usr/share/make-initrd/features/guestfs/rules.mk

--------
MODULES_ADD += drivers/scsi/ drivers/ata/ fs/

guestfs:
        @echo "Adding guestfs support ..."
        @put-tree "$(ROOTDIR)" $(GUESTFS_DATADIR)
        @put-file "$(ROOTDIR)" $(GUESTFS_FILES)

pack: guestfs
--------

в /usr/share/make-initrd/features/guestfs/data/etc/rc.d/init.d/guestfsd
--------
#!/bin/sh
### BEGIN INIT INFO
# Provides:            guestfsd
# Required-Start:      uevent
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start:       3 4 5
# Default-Stop:
# Short-Description:   guestfsd daemon
### END INIT INFO

. /etc/init.d/template

NAME=guestfsd
PIDFILE=/var/run/$NAME.pid
LOCKFILE=/var/lock/subsys/$NAME

start() {

#       start_daemon --lockfile "$LOCKFILE" --pidfile "$PIDFILE"
--displayname "$NAME" -- $NAME
        start_daemon --displayname "$NAME" -- $NAME
        RETVAL=$?
        return $RETVAL

}

stop()
{
        stop_daemon --pidfile "$PIDFILE" --lockfile "$LOCKFILE"
--no-announce -- $NAME
        RETVAL=$?
        return $RETVAL
}

restart()
{
        stop
        start
}

switch "${1-}"

--------

  в /usr/share/make-initrd/features/guestfs/data/etc/udev/rules.d
-----------
# For libguestfs, create /dev/disk/guestfs/<serial>
# and /dev/disk/guestfs/<serial><partnum>

KERNEL=="sd*[!0-9]", ENV{DEVTYPE}=="disk", ENV{ID_SCSI_SERIAL}=="?*", \
  SYMLINK+="disk/guestfs/$env{ID_SCSI_SERIAL}"
KERNEL=="sd*", ENV{DEVTYPE}=="partition", ENV{ID_SCSI_SERIAL}=="?*", \
  SYMLINK+="disk/guestfs/$env{ID_SCSI_SERIAL}%n"

# As written, it's likely the above only works with virtio-scsi
# because ID_SCSI_SERIAL is specific to the output of the 'scsi_id'
# program.  The following will not work because ID_SERIAL contains
# some unwanted text.

#KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", \
#  SYMLINK+="disk/guestfs/$env{ID_SERIAL}"
#KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", \
#  SYMLINK+="disk/guestfs/$env{ID_SERIAL}%n"

-----------

- make-initrd
- chmod 644 /usr/lib64/guestfs/initramfs.x86_64.img

 initrd (appliance) готов. приступаем к тестированию.

export LIBGUESTFS_BACKEND=direct
libguestfs-test-tool
и загрузка виртуалки замерзает на этапе старта udev:
INIT: version 2.88 booting
INIT: Entering runlevel: 3
Mounting filesystem [/dev]: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Mounting filesystem [/proc]: \x1b[72G[
\x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Mounting filesystem [/sys]: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Mounting filesystem [/run]: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Mounting filesystem [/dev/pts]: \x1b[72G[
\x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Parsing cmdline arguments: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Creating /etc/fstab: S30fstab: Root device unspecified.
\x1b[72G[\x1b[1m\x1b[31mFAILED\x1b[39;49m\x1b[0;10m]
Starting lo interface: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Starting timerd service: \x1b[72G[ \x1b[1m\x1b[32mDONE\x1b[39;49m\x1b[0;10m ]
Loading modules before udev:
\x1b[72G[\x1b[1m\x1b[31mFAILED\x1b[39;49m\x1b[0;10m]
Starting udevd service:  Сигнал таймера

Вот тут я не пойму почему udev не стартует, и прошу подсказки, с чем
это может быть связано.
Хочется для начала добиться работы qemu с указанием ядра и initrd,
хоть и без guestfsd.
/usr/bin/qemu-kvm \
    -global virtio-blk-pci.scsi=off \
    -nodefconfig \
    -enable-fips \
    -nodefaults \
    -display none \
    -cpu host \
    -machine accel=kvm:tcg \
    -m 500 \
    -no-reboot \
    -rtc driftfix=slew \
    -no-hpet \
    -global kvm-pit.lost_tick_policy=discard \
    -kernel /usr/lib64/guestfs/vmlinuz.x86_64 \
    -initrd /usr/lib64/guestfs/initramfs.x86_64.img \
    -device virtio-scsi-pci,id=scsi \
    -drive file=/tmp/.private/shabalin/libguestfsrjal5E/scratch.1,cache=unsafe,format=raw,id=hd0,if=none
\
    -device scsi-hd,drive=hd0 \
    -device virtio-serial-pci \
    -serial stdio \
    -device sga \
    -chardev socket,path=/tmp/.private/shabalin/libguestfsrjal5E/guestfsd.sock,id=channel0
\
    -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
    -append 'panic=1 console=ttyS0 udevtimeout=6000
udev.event-timeout=6000 no_timer_check acpi=off printk.time=1
cgroup_disable=memory selinux=0 guestfs_verbose=1 TERM=xterm'


Проблемы упаковки пока тоже в отдаленном будущем.

-- 
Alexey Shabalin

Re: [devel] libguestfs

[Alexey Gladkov]

18.11.2014 18:48, Alexey Shabalin пишет:
> export LIBGUESTFS_BACKEND=direct
> libguestfs-test-tool
> и загрузка виртуалки замерзает на этапе старта udev:
> INIT: version 2.88 booting
> INIT: Entering runlevel: 3
> ...
> Вот тут я не пойму почему udev не стартует, и прошу подсказки, с чем
> это может быть связано.

Фикс в make-initrd добавил. Сейчас новый udev должен стартовать.

> Проблемы упаковки пока тоже в отдаленном будущем.

Думаю в будущем это можно будет оформить в виде фичи.

-- 
Rgrds, legion

Re: [devel] libguestfs

[Alexey Shabalin]

20 ноября 2014 г., 10:16 пользователь Alexey Gladkov
<legion@altlinux.ru> написал:
> 18.11.2014 18:48, Alexey Shabalin пишет:
>> export LIBGUESTFS_BACKEND=direct
>> libguestfs-test-tool
>> и загрузка виртуалки замерзает на этапе старта udev:
>> INIT: version 2.88 booting
>> INIT: Entering runlevel: 3
>> ...
>> Вот тут я не пойму почему udev не стартует, и прошу подсказки, с чем
>> это может быть связано.
>
> Фикс в make-initrd добавил. Сейчас новый udev должен стартовать.

Ок, я получил рабочий initrd. Утилиты guestfs работают. Конечно
"сложные" утилиты, типа конвертации, надо проверять на совместимость с
ALTLinux отдельно. Патчи приветствуются.

>> Проблемы упаковки пока тоже в отдаленном будущем.
>
> Думаю в будущем это можно будет оформить в виде фичи.

А вот теперь возникают проблемы упаковки.
Наш make-initrd не предполагает запуска в сборочнице. Возможен запуск
только в живой системе и от root.
Если переложить проблемы создания initrd на пользователя, то
пользователю придется установить в систему множество "ненужных"
пакетов, которые нужны внутри initrd для guestfs, но не нужны самому
пользователю.
Конечно самый простой способ, это сгенерировать initrd локально,
скопировать ядро и уложить это все в src.rpm.
Но было бы хорошо, если для make-initrd можно было указать корневую
ФС, путь для генерируемого initrd, путь к конфигу, тогда получится
сгенерировать в сборочнице.

-- 
Alexey Shabalin

Re: [devel] libguestfs

[Alexey Gladkov]

27.11.2014 15:17, Alexey Shabalin пишет:
> Но было бы хорошо, если для make-initrd можно было указать корневую
> ФС, путь для генерируемого initrd, путь к конфигу, тогда получится
> сгенерировать в сборочнице.

Всё равно не получится т.к. /lib/modules имеет права 700. Ты не
сможешь скопировать модули ядра для ФС.

Указать место куда положить образ и указать конфиг можно:

-c, --config=FILE      set custom config file;
-b, --bootdir=DIR      set boot directory (default: /boot);

-- 
Rgrds, legion

Re: [devel] libguestfs

[Eugene Prokopiev]

> А вот теперь возникают проблемы упаковки.
> Наш make-initrd не предполагает запуска в сборочнице. Возможен запуск
> только в живой системе и от root.

А как же тогда он умудряется работать в профиле mkimage -
http://git.altlinux.org/people/enp/packages/mkimage-profile-live-minimal-example.git?p=mkimage-profile-live-minimal-example.git;a=blob;f=scripts.d/01-make-initrd;h=203ed81e28505f13a780a435fb81162ed68290ac;hb=460d1033becf9ca5c5be48126354c1e2244543b0
?

> Если переложить проблемы создания initrd на пользователя, то
> пользователю придется установить в систему множество "ненужных"
> пакетов, которые нужны внутри initrd для guestfs, но не нужны самому
> пользователю.

А какова конечная цель? Генерить готовые образы для запуска в
виртуальной среде или делать пакеты с initrd внутри?

-- 
WBR,
Eugene Prokopiev

Re: [devel] libguestfs

[Alexey Shabalin]

27 ноября 2014 г., 16:53 пользователь Eugene Prokopiev <enp@itx.ru> написал:
>> А вот теперь возникают проблемы упаковки.
>> Наш make-initrd не предполагает запуска в сборочнице. Возможен запуск
>> только в живой системе и от root.
>
> А как же тогда он умудряется работать в профиле mkimage -
> http://git.altlinux.org/people/enp/packages/mkimage-profile-live-minimal-example.git?p=mkimage-profile-live-minimal-example.git;a=blob;f=scripts.d/01-make-initrd;h=203ed81e28505f13a780a435fb81162ed68290ac;hb=460d1033becf9ca5c5be48126354c1e2244543b0
> ?

Я как бы всех тонкостей не знаю, вот и выясняю, как запустить
make-initrd внутри хэшера на сборочном сервере.

>> Если переложить проблемы создания initrd на пользователя, то
>> пользователю придется установить в систему множество "ненужных"
>> пакетов, которые нужны внутри initrd для guestfs, но не нужны самому
>> пользователю.
>
> А какова конечная цель? Генерить готовые образы для запуска в
> виртуальной среде или делать пакеты с initrd внутри?

Конечная цель - получить в директории %_libdir/guestfs два файлика:
vmlinuz.${ARCH}
initramfs.${ARCH}.img
мне кажется самым удобным упаковать их в rpm-пакет guestfs-appliance

-- 
Alexey Shabalin

Re: [devel] libguestfs

[Michael Shigorin]

On Thu, Nov 27, 2014 at 06:15:12PM +0400, Alexey Shabalin wrote:
> >> Наш make-initrd не предполагает запуска в сборочнице.
> >> Возможен запуск только в живой системе и от root.
> > А как же тогда он умудряется работать в профиле mkimage - ?
> Я как бы всех тонкостей не знаю, вот и выясняю, как запустить
> make-initrd внутри хэшера на сборочном сервере.

Как вариант, в %post при установке libguestfs?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] libguestfs

[Alexey Shabalin]

27 ноября 2014 г., 17:29 пользователь Michael Shigorin
<mike@altlinux.org> написал:
> On Thu, Nov 27, 2014 at 06:15:12PM +0400, Alexey Shabalin wrote:
>> >> Наш make-initrd не предполагает запуска в сборочнице.
>> >> Возможен запуск только в живой системе и от root.
>> > А как же тогда он умудряется работать в профиле mkimage - ?
>> Я как бы всех тонкостей не знаю, вот и выясняю, как запустить
>> make-initrd внутри хэшера на сборочном сервере.
>
> Как вариант, в %post при установке libguestfs?
Так я и говорю, тогда в системе должно стоять много лишних пакетов
(поддержка всех возможных ФС и т.п.). Поэтому хотелось бы запустить
make-initrd в сборочнице, и результат упаковать в rpm.

-- 
Alexey Shabalin

Re: [devel] libguestfs

[Alexey Gladkov]

27.11.2014 16:53, Eugene Prokopiev пишет:
>> А вот теперь возникают проблемы упаковки.
>> Наш make-initrd не предполагает запуска в сборочнице. Возможен запуск
>> только в живой системе и от root.
> 
> А как же тогда он умудряется работать в профиле mkimage -
> http://git.altlinux.org/people/enp/packages/mkimage-profile-live-minimal-example.git?p=mkimage-profile-live-minimal-example.git;a=blob;f=scripts.d/01-make-initrd;h=203ed81e28505f13a780a435fb81162ed68290ac;hb=460d1033becf9ca5c5be48126354c1e2244543b0
> ?

Обратите внимание на строчки 3 и 4.

Что из модулей положит make-initrd, если autodetect выключен и явно
никаких модулей не перечислено ? :)

-- 
Rgrds, legion

Re: [devel] libguestfs

[Eugene Prokopiev]

27 ноября 2014 г., 17:50 Alexey Gladkov написал:

> Что из модулей положит make-initrd, если autodetect выключен и явно
> никаких модулей не перечислено ? :)

Виртуальное железо не так разнообразно, как настоящее, и поэтому
список необходимых модулей можно подобрать заранее.

Ну а в приведенном выше примере это проблемы пропагатора, которому все
равно приходится скармливать список модулей. Так что если бы
make-initrd еще умел монтировать корень из файла на предварительно
смонтированном разделе, от пропагатора во многих случаях можно было бы
отказаться - и мы как-то это уже обсуждали :)

-- 
WBR,
Eugene Prokopiev

Re: [devel] libguestfs

[Eugene Prokopiev]

27 ноября 2014 г., 17:15 Alexey Shabalin написал:

> Я как бы всех тонкостей не знаю, вот и выясняю, как запустить
> make-initrd внутри хэшера на сборочном сервере.

Вообще-то я поторопился: make-initrd использует hasher внутри себя и
именно поэтому все работает.

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

-- 
WBR,
Eugene Prokopiev

Re: [devel] libguestfs

[Alexey Gladkov]

27.11.2014 20:38, Eugene Prokopiev пишет:
> 27 ноября 2014 г., 17:50 Alexey Gladkov написал:
> 
>> Что из модулей положит make-initrd, если autodetect выключен и явно
>> никаких модулей не перечислено ? :)
> 
> Виртуальное железо не так разнообразно, как настоящее, и поэтому
> список необходимых модулей можно подобрать заранее.

Речь как раз о том, что модули невозможно от пользователя скопировать.

> Ну а в приведенном выше примере это проблемы пропагатора, которому все
> равно приходится скармливать список модулей. Так что если бы
> make-initrd еще умел монтировать корень из файла на предварительно
> смонтированном разделе, от пропагатора во многих случаях можно было бы
> отказаться - и мы как-то это уже обсуждали :)

Опишите пожалуйста ещё раз (я этого обсуждения не видел), какую схему
монтирования корня хочется получить ? Лучше прямо по шагам.

-- 
Rgrds, legion

Re: [devel] libguestfs

[Alexey Gladkov]

27.11.2014 21:04, Eugene Prokopiev пишет:
> 27 ноября 2014 г., 17:15 Alexey Shabalin написал:
> 
>> Я как бы всех тонкостей не знаю, вот и выясняю, как запустить
>> make-initrd внутри хэшера на сборочном сервере.
> 
> Вообще-то я поторопился: make-initrd использует hasher внутри себя и
> именно поэтому все работает.

Надеюсь вы описались о make-initrd. Он не использует hasher совсем :)

-- 
Rgrds, legion

Re: [devel] libguestfs

[Eugene Prokopiev]

27 ноября 2014 г., 21:15 Alexey Gladkov написал:

> Надеюсь вы описались о make-initrd. Он не использует hasher совсем :)

Да, прошу прощения, хотел сказать mkimage :)

-- 
WBR,
Eugene Prokopiev

Re: [devel] libguestfs

[Alexey Shabalin]

27 ноября 2014 г., 21:05 пользователь Alexey Gladkov  написал:
> 27.11.2014 20:38, Eugene Prokopiev пишет:
>> 27 ноября 2014 г., 17:50 Alexey Gladkov написал:
>>
>>> Что из модулей положит make-initrd, если autodetect выключен и явно
>>> никаких модулей не перечислено ? :)
>>
>> Виртуальное железо не так разнообразно, как настоящее, и поэтому
>> список необходимых модулей можно подобрать заранее.
>
> Речь как раз о том, что модули невозможно от пользователя скопировать.

Я вот даже опасаюсь делать запрос в багзиле на пакет filesystem с
просьбой дать доступ пользователю на чтение /boot и /lib/modules.
Простого пользователя туда действительно страшно пускать?


-- 
Alexey Shabalin

Re: [devel] libguestfs

[Alexey Gladkov]

28.11.2014 19:54, Alexey Shabalin пишет:
> Я вот даже опасаюсь делать запрос в багзиле на пакет filesystem с
> просьбой дать доступ пользователю на чтение /boot и /lib/modules.
> Простого пользователя туда действительно страшно пускать?

За спрос денег не берут :)

По крайней мере вопрос про /lib/modules поднимался уже несколько раз.

-- 
Rgrds, legion

Re: [devel] libguestfs

[Dmitry V. Levin]

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

On Fri, Nov 28, 2014 at 08:54:35PM +0400, Alexey Shabalin wrote:
> 27 ноября 2014 г., 21:05 пользователь Alexey Gladkov  написал:
> > 27.11.2014 20:38, Eugene Prokopiev пишет:
> >> 27 ноября 2014 г., 17:50 Alexey Gladkov написал:
> >>
> >>> Что из модулей положит make-initrd, если autodetect выключен и явно
> >>> никаких модулей не перечислено ? :)
> >>
> >> Виртуальное железо не так разнообразно, как настоящее, и поэтому
> >> список необходимых модулей можно подобрать заранее.
> >
> > Речь как раз о том, что модули невозможно от пользователя скопировать.
> 
> Я вот даже опасаюсь делать запрос в багзиле на пакет filesystem с
> просьбой дать доступ пользователю на чтение /boot и /lib/modules.
> Простого пользователя туда действительно страшно пускать?

https://bugzilla.altlinux.org/show_bug.cgi?id=5969

Одного только номера достаточно, чтобы все стало ясно. :)


-- 
ldv

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

Re: [devel] libguestfs

[Alexey Gladkov]

28.11.2014 20:03, Dmitry V. Levin пишет:
> https://bugzilla.altlinux.org/show_bug.cgi?id=5969

Времена меняются и modutils и module-init-tools у нас не используются.
Сейчас модули грузятся libkmod, которая не использует fcntl.

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

-- 
Rgrds, legion

Re: [devel] libguestfs

[Alexey Shabalin]

28 ноября 2014 г., 20:03 пользователь Dmitry V. Levin
<ldv@altlinux.org> написал:
> On Fri, Nov 28, 2014 at 08:54:35PM +0400, Alexey Shabalin wrote:
>> 27 ноября 2014 г., 21:05 пользователь Alexey Gladkov  написал:
>> > 27.11.2014 20:38, Eugene Prokopiev пишет:
>> >> 27 ноября 2014 г., 17:50 Alexey Gladkov написал:
>> >>
>> >>> Что из модулей положит make-initrd, если autodetect выключен и явно
>> >>> никаких модулей не перечислено ? :)
>> >>
>> >> Виртуальное железо не так разнообразно, как настоящее, и поэтому
>> >> список необходимых модулей можно подобрать заранее.
>> >
>> > Речь как раз о том, что модули невозможно от пользователя скопировать.
>>
>> Я вот даже опасаюсь делать запрос в багзиле на пакет filesystem с
>> просьбой дать доступ пользователю на чтение /boot и /lib/modules.
>> Простого пользователя туда действительно страшно пускать?
>
> https://bugzilla.altlinux.org/show_bug.cgi?id=5969
>
> Одного только номера достаточно, чтобы все стало ясно. :)

я правильно понимаю, что на текущий момент есть два выхода:
1) "на секундочку" сделать доступными /boot и /lib/modules с помощью
пакета, типа rpm-build-guestfs, где в %post будет
chmod 644 /boot
chmod 644 /lib/modules

или
2) сделать своё ядро kernel-image-vm-def для работы внутри гостевых
систем, и на этапе сборки готовить initrd-имидж для guestfs, пока в
сборочнице есть доступ к ядру и модулям.

-- 
Alexey Shabalin

Re: [devel] /lib/modules/ access permissions (was: libguestfs)

[Dmitry V. Levin]

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

On Sun, Nov 30, 2014 at 12:34:32AM +0300, Alexey Gladkov wrote:
> 28.11.2014 20:03, Dmitry V. Levin пишет:
> > https://bugzilla.altlinux.org/show_bug.cgi?id=5969
> 
> Времена меняются и modutils и module-init-tools у нас не используются.
> Сейчас модули грузятся libkmod, которая не использует fcntl.

Да, libkmod не занимается блокировкой файлов модулей, там все просто:
	open O_RDONLY
	mmap PROT_READ MAP_PRIVATE
	finit_module
(с разновидностями вида gzdopen/gzread с последующим init_module,
если поддерживаются сжатые модули).

В ушедшем module-init-tools тоже на авось:
	open O_RDONLY
	read в цикле
	init_module

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

Давайте обсудим.  Очевидно, что потенциальный DoS путем блокировки файла
модуля сейчас уже не реализуем.


-- 
ldv

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

Re: [devel] /lib/modules/ access permissions

[Alexey Gladkov]

30.11.2014 02:47, Dmitry V. Levin пишет:
> Да, libkmod не занимается блокировкой файлов модулей, там все просто:
> 	open O_RDONLY
> 	mmap PROT_READ MAP_PRIVATE
> 	finit_module
> (с разновидностями вида gzdopen/gzread с последующим init_module,
> если поддерживаются сжатые модули).
> 
> В ушедшем module-init-tools тоже на авось:
> 	open O_RDONLY
> 	read в цикле
> 	init_module
> 
>> Я думаю, что описанная в баге проблема должна быть обсуждена ещё раз.
> 
> Давайте обсудим.  Очевидно, что потенциальный DoS путем блокировки файла
> модуля сейчас уже не реализуем.

Сейчас я не могу придумать зачем могут быть нужны ограничения на этот
каталог. Там есть дополнительная информация о том, какие модули
находится в ядре, но с другой стороны эту же информацию можно
почерпнуть в /proc/config.gz, который доступен на чтение.

-- 
Rgrds, legion

Re: [devel] /lib/modules/ access permissions (was: libguestfs)

[Alexey Shabalin]

30 ноября 2014 г., 2:47 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Sun, Nov 30, 2014 at 12:34:32AM +0300, Alexey Gladkov wrote:
>> 28.11.2014 20:03, Dmitry V. Levin пишет:
>> > https://bugzilla.altlinux.org/show_bug.cgi?id=5969
>>
>> Времена меняются и modutils и module-init-tools у нас не используются.
>> Сейчас модули грузятся libkmod, которая не использует fcntl.
>
> Да, libkmod не занимается блокировкой файлов модулей, там все просто:
>         open O_RDONLY
>         mmap PROT_READ MAP_PRIVATE
>         finit_module
> (с разновидностями вида gzdopen/gzread с последующим init_module,
> если поддерживаются сжатые модули).
>
> В ушедшем module-init-tools тоже на авось:
>         open O_RDONLY
>         read в цикле
>         init_module
>
>> Я думаю, что описанная в баге проблема должна быть обсуждена ещё раз.
>
> Давайте обсудим.  Очевидно, что потенциальный DoS путем блокировки файла
> модуля сейчас уже не реализуем.

Привели ли обсуждения к каким-нибудь результатам? Ждать ли каких-либо
изменений в пакете filesystem?


-- 
Alexey Shabalin

Re: [devel] /lib/modules/ access permissions (was: libguestfs)

[Dmitry V. Levin]

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

On Fri, Dec 05, 2014 at 05:14:36PM +0400, Alexey Shabalin wrote:
> 30 ноября 2014 г., 2:47 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> > On Sun, Nov 30, 2014 at 12:34:32AM +0300, Alexey Gladkov wrote:
> >> 28.11.2014 20:03, Dmitry V. Levin пишет:
> >> > https://bugzilla.altlinux.org/show_bug.cgi?id=5969
> >>
> >> Времена меняются и modutils и module-init-tools у нас не используются.
> >> Сейчас модули грузятся libkmod, которая не использует fcntl.
> >
> > Да, libkmod не занимается блокировкой файлов модулей, там все просто:
> >         open O_RDONLY
> >         mmap PROT_READ MAP_PRIVATE
> >         finit_module
> > (с разновидностями вида gzdopen/gzread с последующим init_module,
> > если поддерживаются сжатые модули).
> >
> > В ушедшем module-init-tools тоже на авось:
> >         open O_RDONLY
> >         read в цикле
> >         init_module
> >
> >> Я думаю, что описанная в баге проблема должна быть обсуждена ещё раз.
> >
> > Давайте обсудим.  Очевидно, что потенциальный DoS путем блокировки файла
> > модуля сейчас уже не реализуем.
> 
> Привели ли обсуждения к каким-нибудь результатам? Ждать ли каких-либо
> изменений в пакете filesystem?

Слегка обсудили только один вопрос (о блокировках файлов модулей)
и пришли к выводу, что блокировок уже нет.

Вопрос о доступе к vmlinuz (и полученному из него System.map) и модулям
с точки зрения автоматизации атаки на ядро не обсуждался совсем.


-- 
ldv

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

Re: [devel] libguestfs

[Dmitry V. Levin]

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

On Sun, Nov 30, 2014 at 03:37:58AM +0400, Alexey Shabalin wrote:
> 28 ноября 2014 г., 20:03 пользователь Dmitry V. Levin
> <ldv@altlinux.org> написал:
> > On Fri, Nov 28, 2014 at 08:54:35PM +0400, Alexey Shabalin wrote:
> >> 27 ноября 2014 г., 21:05 пользователь Alexey Gladkov  написал:
> >> > 27.11.2014 20:38, Eugene Prokopiev пишет:
> >> >> 27 ноября 2014 г., 17:50 Alexey Gladkov написал:
> >> >>
> >> >>> Что из модулей положит make-initrd, если autodetect выключен и явно
> >> >>> никаких модулей не перечислено ? :)
> >> >>
> >> >> Виртуальное железо не так разнообразно, как настоящее, и поэтому
> >> >> список необходимых модулей можно подобрать заранее.
> >> >
> >> > Речь как раз о том, что модули невозможно от пользователя скопировать.
> >>
> >> Я вот даже опасаюсь делать запрос в багзиле на пакет filesystem с
> >> просьбой дать доступ пользователю на чтение /boot и /lib/modules.
> >> Простого пользователя туда действительно страшно пускать?
> >
> > https://bugzilla.altlinux.org/show_bug.cgi?id=5969
> >
> > Одного только номера достаточно, чтобы все стало ясно. :)
> 
> я правильно понимаю, что на текущий момент есть два выхода:
> 1) "на секундочку" сделать доступными /boot и /lib/modules с помощью
> пакета, типа rpm-build-guestfs, где в %post будет
> chmod 644 /boot
> chmod 644 /lib/modules

Если сделать 644 на каталоги, то лучше точно не станет. :)
Тогда уж a+x.

> или
> 2) сделать своё ядро kernel-image-vm-def для работы внутри гостевых
> систем, и на этапе сборки готовить initrd-имидж для guestfs, пока в
> сборочнице есть доступ к ядру и модулям.

Не стоит собирать свое ядро - оно протухнет.

Еще один вариант, если доступа к каталогам /boot и /lib/modules нет -
скопировать (cp -al) оттуда нужные файлы в %post соответствующего пакета.


-- 
ldv

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