Bounty: добавить в mksquashfs поддержку чтения из tar напрямую (docker -> squash)

Когда в CI под не рутом распаковываешь tar в директорию, что бы из неё сделать squashfs, то убиваются все права, владение файлами и нельзя сделать файлы из /dev

А как промежуточное решение нельзя сделать распаковку и запаковку из-под не-root'а с использованием fakechroot/fakeroot? ЕМНИП, кто-то из них в отдельном файлике сохраняют права и овнершипы на файлы, да и mknod вроде из-под них можно вызывать.

подписался, интересная была бы фича для sqsh

Интересная и вроде полезная фича, я готов запилить. С распаковкой tar бывало ещё натыкался на проблему со спец файлом /dev/null, когда хотел конвертировать образ alpine в репозиторий ostree.

Кода не много, думаю можно за пару дней уложиться - время у меня пока есть. Мой телеграм с тем же ником, почта тоже - на gmail.

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

монтирование требует рута. Это неудобно

мне присылают в личку варианты с archivemount, fusermount.

Этот вариант я не рассматриваю, спасибо.

А запуск mksquashfs в непосредственно в контейнере?

в контейнере как правило всё легче.

Я хочу обойтись без linux root only вещей.

Коллеги, первый человек уже взялся за работу.

Я разверну вопрос свой: а почему не рассматривается запуск mksquashfs в контейнере, раз уж докер используется?

Разве это не дешевле, чем патчить сквош-тулз?

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

ясно, то есть, основной мотив - «я хочу»? ладно..

мне просто был интересен технический профит от этого )

— зачем ты хочешь С, если есть простой понятный ассемблер — ну я так хочу — т.е. основной мотив «я хочу?»

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

Я хочу иметь инструменты, которые как можно меньше зависят от окружения

Так, вроде, как раз нутро контейнера минимально зависит от окружения как раз…

(Спасибо за ответ, я сворачиваю флудильню в джобе ;) )

первый человек уже взялся за работу

Каков примерно ожидаемый срок? Мне очень интересно посмотреть на реализацию.

сейчас прорабатывается идея сделать поверх tar индекс для mksquashfs: т.е. не прямая поддержка формата tar, а список из имен файлов, смещений внутри tar и пермишнов.

Совсем не так, как я себе это представлял.

С первым человеком не получилось решить эту проблему.

Как именно вы себе видите решение?

Во избежание недоразумений: я не собираюсь браться за эту задачу.

Думаю, там стоило бы поменять прямые вызовы opendir()/readdir()/open()/read() на косвенные, и так подменять их на собственные реализации, когда обрабатываются tar-файлы. Хотел посмотреть, совпадёт ли это с подходом реального исполнителя.

звучит разумно. Собственный vfs слой

Думаю, там стоило бы поменять прямые вызовы opendir()/readdir()/open()/read() на косвенные, и так подменять их на собственные реализации, когда обрабатываются tar-файлы.

Сложность в том, что к tar придётся писать индекс на голой сишечке, т.к. mksquashfs сначала строит дерево каталогов, а потом читает файлы случайным доступом. А ещё в tar распространены хардлинки, которые хранятся в архиве как симлинки - их тоже нужно аккуратно склеивать.
Всё это делает конструкцию решения уязвимой к малейшим изменениям в ТЗ будь то добавления компрессии или использования докерного «послойного» tar (delta-tars внутри tar). А автор, как мне показалось, ещё не до конца определился, что конкретно нужно.

Всё это делает конструкцию решения уязвимой к малейшим изменениям в ТЗ будь то добавления компрессии или использования докерного «послойного» tar

Нельзя сделать всех счастливыми.

https://github.com/flussonic/squashfs-tools

всё готово, сделано быстро и четко.

Спасибо!