Установка программ в Slackware

[yars]

Прав рута требуют только вот эти места в слакбилде:

Код: Выделить всё

...
chown -R root:root $PKGNAM-$VERSION
...
make install DESTDIR=...
...
/sbin/makepkg ...

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

[Bizdelnick]

Прав рута требуют только вот эти места в слакбилде:

Код: Выделить всё

...
chown -R root:root $PKGNAM-$VERSION
...
make install DESTDIR=...
...
/sbin/makepkg ...

Я в этих ваших слакварях ничего не понимаю, но...
Во-первых, для make install DESTDIR=... требуются только лишь права на запись в $(DESTDIR) и вложенные каталоги. Соответственно, если они принадлежат юзеру, рутовые права для этого не нужны.
Во-вторых, делать chown -R root:root тоже не имеет смысла. Если нужно, чтобы владельцем всех файлов в тарболе стал root, можно просто передать tar'у опции --owner=root --group=root.
Вот что делает makepkg - понятия не имею, так что про него ничего не скажу.

[yars]

А эта возможность у tar когда появилась? pkgtools используют tar 1.13, на который накладывается патч для поддержки bzip2. А makepkg генерирует (или корректирует) $PKG/install/doinst.sh, задача которого - послеустановочная доводка пакета, которая заключается в проверке приходящих конфигов и восстановление симлинков, которые makepkg удаляет при создании пакета. После генерации doinst.sh собственно и создается пакет путем помещения дерева файлов и каталогов $PKG в архив tar, сжатый одним из методов компрессии, наибольшее распространение получили gzip и xz, последний применяется в новейших версиях Slackware.

[Bizdelnick]

А эта возможность у tar когда появилась?

Если верить ченжлогу, 1996-04-23, в версиях 1.11.x.

[yars]

Тогда причина чисто историческая. Да и необходимости менять владельца исходников я не вижу, достаточно обеспечить права на чтение и запись в каталог $PKGNAM-$VERSION, в который распаковываются исходники.

[bormant]

Еще есть случаи, когда владельцем отдельных файлов/каталогов должен быть не root:root. А так да, исторически сложилось, обойти для большинства случаев возможно, но поскольку использовать fakeroot проще, обычно им и пользуются, когда не хотят весь или часть сценария исполнять от рута..

[drBatty]

Я в этих ваших слакварях ничего не понимаю

у нас принято slackbuilds выполнять от root.

Во-первых, для make install DESTDIR=... требуются только лишь права на запись в $(DESTDIR) и вложенные каталоги. Соответственно, если они принадлежат юзеру, рутовые права для этого не нужны.

рутовые права нужны тут для того, что-бы владельцем файлов в будущем пакете был рут.

Вот что делает makepkg

простой скрипт, который упаковывает каталог в пакет, ну и ещё некоторые фичи там есть.

[sunny1983]

drBatty, вот ясно и чётко ответил о том как положено делать, а не как можно.
А вы согласны с тем, что сборка пакетов из слакбилдов - процесс небезопасный. Даже если программист не замышлял ничего дурного, слакбилд и вызываемый им make-скрипт могут, например, оставлять в системе остаточные продукты компиляции. Я вот тут в соседней теме писал о сборке пакетов в сандбоксе, как считаете: правильно или излишество.

[Bizdelnick]

рутовые права нужны тут для того, что-бы владельцем файлов в будущем пакете был рут.

Если нужно, чтобы владельцем всех файлов в тарболе стал root, можно просто передать tar'у опции --owner=root --group=root.

[drBatty]

А вы согласны с тем, что сборка пакетов из слакбилдов - процесс небезопасный.

да. Потому слакобилды на slackbuilds.org подписаны ЭЦП. И эту ЭЦП нужно проверять. Неплохо и посмотреть, ЧТО делает этот скрипт.

могут, например, оставлять в системе остаточные продукты компиляции.

"продукты" остаются в $TMP, обычно это /tmp, который я монтирую в память. Если вы монтируете его не в память, то да, надо чистить. Иногда и при монтировании в память приходится чистить, т.к. место кончается, RAM не резиновая к сожалению.

Я вот тут в соседней теме писал о сборке пакетов в сандбоксе, как считаете: правильно или излишество.

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

Код: Выделить всё

./configure --prefix=PREFIX

с помощью которых можно поставить программу куда угодно, например в $HOME, и она даже будет там работать (маздайщики называют это "портабельная программа"), если вы конечно не поставили noexec на /home. Потому ваша песочница конечно избыточна и не нужна. Разве что для ядра(модулей, кривого/закрытого ПО и прочего не нужно).

Bizdelnick ну зачем вы мне это говорите, скажите Патрегу, что ваш способ намного более Ъ и более православный. А то Патрег не понимает, зачем ему это менять? Особой безопасности это всё равно не даст, ибо враг может ведь и в сам пакет гадости напихать, который вы под рутом будете ставить в /usr. Смысл собирать от пользователя?

[sunny1983]

Разве что для ядра(модулей, кривого/закрытого ПО и прочего не нужно).

Так именно прочее собирать и приходится. Нормальные программы обычно уже собраны до тебя и лежат в репозитории.
К тому же не все программы собираются при помощи make и имеют скрипт configure.
Не могу вспомнить подходящий пример, но хотя бы nvidia-kernel.Slackbuild

[bormant]

sunny1983
примером может быть Bumblebee, в установочном сценарии которого по ошибке был добавлен пробел после /usr:

Код: Выделить всё

rm -rf /usr /lib/nvidia-current/xorg/xorg

Собирая в песочнице, от подобных ошибок на стадии сборки вы будете застрахованы разрушением песочницы, а не основной системы.
Правда та ошибка была в установочном сценарии, исполняемом при установке пакета от рута, и этой ошибки на живой системе можно было избежать, только обнаружив ее при тестовой установке в песочнице.

А главный вопрос, как всегда, в соотношении получаемого результата и затрачиваемых усилий. Иногда наличие бэкапа является "более лучшим" решением, чем турусы на колесах вокруг опасного процесса. Иногда песочница нужна прежде всего для создания чистого эталонного сборочного окружения (например, чтобы предназначенный для распространения пакет не цеплял лишние зависимости, установленные у сборщика, но, скорее всего, отсутствующие у целевой аудитории), а защиту основной системы от процесса сборки мы получим "без-воз-мезд-но, то есть даром".

Ах да, для root-а не является проблемой "выпрыгнуть" из chroot -- от таких целенаправленных действий песочница не защищает.

[alv]

Смысл собирать от пользователя?

А это как в анекдоте про монахиню и морковку: бережёного бог бережёт.

А главный вопрос, как всегда, в соотношении получаемого результата и затрачиваемых усилий.

Вот именно, как говорит t.t

Так именно прочее собирать и приходится.

А может, лучше просто не собирать кривой и потенциально небезопасный софт?
Чему хороший пример

может быть Bumblebee

С которого всё равно толку что с козла молока.

[alv]

slapt-get и slapt-src кажется являются официальными инструментами управления пакетами дистрибутива Salix.

обе утилиты были написаны в своё время для Slackware, в каковой и могут быть установлены любым стандартным методом
вот только полноценно использовать их можно со считанным количеством репозиториев, в которых поддерживаются зависимости
в том числе с репозиторием Salix'а
а так более-менее полный список таковых http://alv.me/?p=5668
ну и на http://alv.me/?p=5668 для каждого репозитория указано, поддерживает он зависимости или нет

[sunny1983]

Ах да, для root-а не является проблемой "выпрыгнуть" из chroot -- от таких целенаправленных действий песочница не защищает.

Ну я не думаю, что найдутся маньяки, которые алгоритм побега из chroot в слакбилд прописывать будут.

[Bizdelnick]

скажите Патрегу, что ваш способ намного более Ъ и более православный. А то Патрег не понимает, зачем ему это менять? Особой безопасности это всё равно не даст, ибо враг может ведь и в сам пакет гадости напихать, который вы под рутом будете ставить в /usr. Смысл собирать от пользователя?

Так он моего мнения не спрашивал, чего я к нему полезу?
Что касается пихания в пакет гадости - то опасность вовсе не в этом. Опасность не для юзера, а для майнтейнера. Ну например пишете Вы слакбилд, по привычке вставляете make install DESTDIR=..., а разработчики ничего про DESTDIR в мейкфайле и не написали. В итоге запишете себе что-то неведомое прямо в корень, ещё и затерев системные файлы.

[yars]

Bizdelnick, да, проблемка неприятная, потому и "доверяй, но проверяй". Неприятная, но не фатальная. Ежу понятно, что, собирая собственный пакет, следует заглянуть в тарбол с исходниками, убедиться, что возможность беспроблемной сборки есть, и только после этого уже можно писать слакбилд. И лог сборки может быть полезен, потому-то, например, слакбилды Инопланетянина сохраняют логи, по каждому из крупных сборочных действий отдельно. И да, иногда вместо make install DESTDIR=$PKG применяют make в связке с установкой каждого файла с помощью команды install.

[drBatty]

Не могу вспомнить подходящий пример, но хотя бы nvidia-kernel.Slackbuild

они и не собираются. Там блоб вставляется в систему, а собирается только прокладка между блобом и ядром.

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

вот именно об этом я и говорил. Сама сборка и упаковка пакета происходит внутри $TMP, и ничего кроме него порушить не может. За то порушить может tar, который запускается при установке, и/или постустановычный скрипт. От этого вас песочница для сборки не убережёт.

А это как в анекдоте про монахиню и морковку: бережёного бог бережёт.

фактически оно и так в песочнице $TMP копошиться, и выпрыгивать оттуда не должно. А уж если автор скрипта решил подложить вам свинью, то это будет куда как проще и незаметнее сделать при установке пакета. Да и это таки надёжнее, ведь админ сервера не обязательно будет собирать пакет на этом сервере. Как раз скорее всего админ выстроит аналогичное окружение на своём локалхосте и там и соберёт. И какой смысл заражать это окружение?

Ну я не думаю, что найдутся маньяки, которые алгоритм побега из chroot в слакбилд прописывать будут.

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

Ну например пишете Вы слакбилд, по привычке вставляете make install DESTDIR=..., а разработчики ничего про DESTDIR

не, ну я сначала у себя в $HOME собираю. На в принципе да, проблема может появится.

[alv]

И какой смысл заражать это окружение?

Так Вi чо, анекдот про монахиню с морковкой таки не знаете?
Рассказал бы, да боюсь, тутошние пуристы осудят и забанят.

[drBatty]

Так Вi чо, анекдот про монахиню с морковкой таки не знаете?

какой именно? Я так понял, что вы про кондом на морковке, да?

Я вполне серьёзно вам говорю: усложнение системы защиты ведёт к снижению общей безопасности. Т.е. эти ваши дополнительные меры дают прямо противоположный эффект.

Канонiчный примеръ: Windows™, в которой очень сложная и многоуровневая защита, тут у нас и ACL, и антивирус, и фаервол с гуем, и UAC, и ещё много чего нужного. Ну и каков итог этой защиты? РЕШЕТО.

[alv]

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

Это Вi мне объясняете? Или где?

[sunny1983]

Фактически оно и так в песочнице $TMP копошиться, и выпрыгивать оттуда не должно.

Можно пример слакбилда в котором чрут в песочницу $TMP присутствует?

[drBatty]

Фактически оно и так в песочнице $TMP копошиться, и выпрыгивать оттуда не должно.

Можно пример слакбилда в котором чрут в песочницу $TMP присутствует?

зачем там chroot? Под "песочницей" я имел ввиду каталог. И то, что во время сборки оттуда не нужно выходить злоумышленнику. Если враг готовит пакет, он может его сделать и от имени простого пользователя. Потому я не понимаю смысл защищать систему при сборке? От каких опасностей мы защищаемся? Только имеем лишние проблемы.

[sunny1983]

Как осуществляется сборка пакета:
1. загрузка архива исходников и вспомогательных файлов.
2. Распаковка исходников
3. Вызов сценариев конфигурирования и компиляции
4. Вызов сценария установки
5. Копирование всех файлов, появившихся в системе на этапе 4 в каталог сборки в /tmp
6. Создание в каталоге сборки каталога install, копирование туда slack-desc, копирование вспомагательных файлов
7. Упаковка пакета при помощи makepkg

Остаточные продукты компиляции могут остаться в системе как раз на этапе 4. И, если для программ с открытым исходным кодом, собирающихся при помощи make этого можно избежать изменив корень на $TMP (я так понимаю вы имеете в виду именно это), то как поступить со всеми остальными программами? Ведь есть ещё программы неконфигурируемые, прогрыммы собирающиеся через CMAKE вместо MAKE, прграммы проприетарные, устанавливающиеся программой-инсталлятором. Как быть с ними?

[Bizdelnick]

Ведь есть ещё программы неконфигурируемые, прогрыммы собирающиеся через CMAKE вместо MAKE, прграммы проприетарные, устанавливающиеся программой-инсталлятором. Как быть с ними?

В каждом случае - индивидуально. С cmake всё просто: cmake -DCMAKE_INSTALL_PREFIX=$DESTDIR/usr/local (или в какой там префикс принято в slackware устанавливать?). У неконфигурируемых программ надо лезть в мейкфайл и смотреть, как они устанавливаются. Обычно проблема решается переопределением какой-то переменной, но она может называться не DESTDIR, а, например, INSTALL_DIR. Если такой нет, то наверняка есть хотя бы PREFIX или INSTALL_PREFIX. В инсталляторах надо в кишках ковыряться, обычно они состоят из shell-скриптов и tar-архивов.

[bormant]

sunny1983
остаточные продукты компиляции и иной мусор появляется на шагах 1 (загруженные исходники), 2 (распакованные исходники, обычно куда-то в /tmp/progname-version), 3 (файлы, порожденные при сборке), 4 (временный каталог становки, который будет затем упаковываться при помощи makepkg, обычно /tmp/pkg-progname), 5 (на самом деле тут доустанавливается документация и прочее ридми/лицензе в /tmp/pkg-progname/usr/doc/pkgname-version/), 6 (/tmp/pkg-progname/install/), 7 (укладка дерева /tmp/pkg-progname/ в пакет). 8 после установки пакета в систему он тоже мусор :-) если его не надо поставить где-то ещё, с этой целью его можно куда-то в сторону скопировать.
После шага 8 всё от предыдущих шагов -- мусор, возможно тарболы исходников стоит оставить до выхода следующей версии на случай пересборки с другими параметрами.

Как чистить описанный выше мусор?
Если чистится /tmp, то весь описанный мусор благополучно погибает при чистке /tmp сам по себе.
Если не чистится, никто не мешает по завершении сборки пакета сказать rm -r /tmp/progname-version/ /tmp/pkg-progname/ (слакбилды со slackbuilds.org все вышеописанное делают в /tmp/SBo/ вместо /tmp), некоторые слакбилды содержат ключик --cleanup именно для удаления после себя этой пары каталогов.

[sunny1983]

bormant
Мусор, который оседает в /tmp за мусор можно и не считать. Вот если что-нибудь осядет в /usr, /var или /etc
Установите любой пакет с конфигами, например установите bind и тут же удалите его - у вас останется файл /etc/rc.d/rc.bind, потому как устанавливался не он, а /etc/rc.d/rc.bind.new - защита от затирания конфига при обновлении пакета.
Слакбилды с slackbuilds.org может и умеют чистить после себя мусор, но... ладно будет живой пример, тогда и приведу. В любом случае, данный Bizdelnick совет "в кишках ковыряться" мне кажется нерациональным. Не готов как-то я к этому.
Мне нужно установить драйвера NVIDIA версии 100.14.11. На slackbuilds.org есть только 173.14.38, 304.108 и 96.43.23.

[bormant]

sunny1983
удалять конфиги бездумно не принято, ибо обычно они содержат некую проделанную администратором работу над ними.
Но это не значит, что нельзя, ежели хочется. Возьмём ваш пример:

Код: Выделить всё

# removepkg bind

# sed -ne '/.new$/ s/.new$//p' $(ls /var/adm/removed_packages/bind-* | grep -v upgraded-)
etc/named.conf
etc/rc.d/rc.bind

Для удаления достаточно добавить к последней команде "| xargs rm".

Выполнять удаление, предварительно перейдя в корневой каталог!!!

ps. Или до удаления пакета:

Код: Выделить всё

# (cd /; sed -ne '/.new$/ s/.new$//p' /var/adm/packages/bind-[0-9]* | xargs rm)
# removepkg bind

pps. Другой (пожалуй, идеологически более правильный) способ получения списка файлов .new -- из установочных сценариев:

Код: Выделить всё

# grep '^\s*config\s*[^\(]' /var/adm/removed_scripts/bind-[0-9]*
# grep '^\s*config\s*[^\(]' /var/adm/scripts/bind-[0-9]*

Где взять -- показал, как взять остаётся в качестве домашнего задания :-)

[bormant]

Мне нужно установить драйвера NVIDIA версии 100.14.11. На slackbuilds.org есть только 173.14.38, 304.108 и 96.43.23.

В качестве отправной точки:

Код: Выделить всё

# mkdir ~/bld; cd ~/bld
# wget http://slackbuilds.org/slackbuilds/14.1/system/nvidia-legacy96-{kernel,driver}.tar.gz
# tar xf nvidia-legacy96-kernel.tar.gz
# tar xf nvidia-legacy96-driver.tar.gz
# sed -i -e 's/96.43.23/100.14.11/g' nvidia-legacy96-{kernel,driver}/*{info,Build}

# cd nvidia-legacy96-kernel
# . *info; wget $DOWNLOAD_x86_64; ./*Build
# upgradepkg --install-new /tmp/nvidia-legacy96-kernel-*t?z

# cd ../nvidia-legacy96-driver
# mv ../nvidia-legacy96-kernel/*.run .
# . *info; wget -c $DOWNLOAD_x86_64; ./*Build
# upgradepkg --install-new /tmp/nvidia-legacy96-driver-*t?z

[Bizdelnick]

Мне нужно установить драйвера NVIDIA версии 100.14.11. На slackbuilds.org есть только 173.14.38, 304.108 и 96.43.23.

А в связи с чем такая странная потребность? Поддержка старых карточек дропалась именно после 96 и 173 версий. То есть если карточка работает с 100, то она будет работать и с 173.