digiKam из flatpak — доступ к файлам

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

Почему: вообще на данный момент во Flatpak проблема доступа приложений к файлам пользователя решается через «порталы». А именно, приложение, когда ему нужно считать какой-то пользовательский файл, вместо того, чтобы отрисовать диалог открытия самостоятельно, отправляет специальный запрос рантайму Flatpak, который рисует этот диалог самостоятельно и в конечном итоге отдаёт приложению только тот файл, который выбран пользователем. Других способов доступа к файлам пользователя во Flatpak не предусмотрено (ну кроме --filesystem=host).

Для DT и GIMP и прочих этот способ подходит, т. к. они работают с отдельными, конкретными файлами пользователя (с прямого ведома и указания пользователя открывается конкретный файл ⇒ приложение с ним работает ⇒ приложение однократно сохраняет результат в тот же файл). Поэтому там как раз нужно выкинуть --filesystem=host и поддержать порталы в коде приложения. Но в случае digiKam ему нужен доступ ко всей коллекции и сразу, а также прямой посиксовый доступ к файлам БД. Как это идиоматично решить во флатпаке, мне неизвестно.

Так что если хочется поучаствовать, задай вопрос в рассылку.

Порталы поддерживаются не всеми тулкитами. Только GTK3 уже поддерживает всё, Qt5 пока не поддерживает проброс каталогов. Когда начнёт - разрешения на прямой доступ к ФС станут не нужны.

Flatseal

Ого, прикольно, буду знать!

Я в курсе. Перечитай ещё раз мой комментарий — речь идёт о ситуациях, когда существующие порталы (рассчитанные на интерактивный доступ к отдельным файлам) не подходят.

А ты перечитай мой. Через портал можно давать доступ к каталогам, а не только отдельным файлам. GTK3 это поддерживает, Qt5 пока нет.

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

Ты бы яснее выражался, что ли, а то из твоего первого комментария это вообще не особо понятно.

Но как бы там ни было, это всё равно не о том. Пользователю нужно будет при каждом запуске digikam заново выбирать каталог с базой и каталог с фоточками (которых может быть несколько).

Почему при каждом запуске? Только один раз для каждого каталога.

И эта информация куда-то сохраняется внутри Flatpak? Как это работает? Выбранные пользователем каталоги автоматически добавляются в разрешения или просто последующие обращения к тому же порталу с теми же аргументами аппрувятся автоматически?

Сохраняется, да. После того, как юзер выберет файл/каталог, портал возвращает тулкиту путь к примонтированному внутрь песочницы файлу/каталогу вида /run/user/1000/doc/asd123/, и он остаётся там же при последующих запусках.

Посмотреть, что кому разрешено, можно в flatpak document-list --columns=all.

Мы сейчас говорим об org.freedesktop.portal.Documents? Я вообще не вижу там ни единого упоминания, что им можно прокидывать каталоги. И вообще он какой-то наркоманский.

Ну и

Exported files will be made accessible to the application via a fuse filesystem

Удачи этот портал использовать для внутренней БД.

Изнутри песочницы вызывается org.freedesktop.portal.FileChooser.OpenFile(), там есть опция directory.

Удачи этот портал использовать для внутренней БД.

Внутренняя БД, скорее всего, лежит где-нибудь в $XDG_DATA_HOME, а не в произвольном месте, которое надо выбрать юзеру.

отдаёт приложению только тот файл, который выбран пользователем

То есть флатпакофанатики пытаются скатить нативные приложения до уровня анально огороженной вебни? И это в то время, когда в хромоге наоборот — пилят API для доступа к целым директориям, потому что так жить нельзя?

Изнутри песочницы вызывается org.freedesktop.portal.FileChooser.OpenFile(), там есть опция directory.

Допустим. Ну если потом каталог можно открыть и передать fd в document portal и это сработает, тогда хорошо. Ну как «хорошо»: удачи переписать ядро digikam, чтобы абстрагировать его от реальных путей к файлам и заставить код БД думать, что /run/user/1000/foobar/bazquux — это то же самое, что /mnt/data/path/to/bazquux. Мне кажется, что это случится примерно никогда.

Вот что мешало монтировать FUSE прямо в то место, где лежит затребованный файл? Или просто bind-монтировать файл/каталог с хоста в песочницу вместо всей свистопляски с виртуальными путями и «документами»?

Алсо, UX у этого дела просто восхитительный. Я так и вижу, как юзер запускает digikam во флатпаке (до этого пользовавшись нативным), открывает свою БД и digikam такой говорит: сейчас вам будет четыре раза подряд показан диалог открытия каталога, выберите в первом /foo, во втором /bar, в третьем /baz и в четвёртом /quux. Не перепутайте и не ошибитесь, потому что реальных путей нам отсюда не видно.

Наркомания.

Внутренняя БД, скорее всего, лежит где-нибудь в $XDG_DATA_HOME, а не в произвольном месте, которое надо выбрать юзеру.

Нет.

Ну как «хорошо»: удачи переписать ядро digikam, чтобы абстрагировать его от реальных путей к файлам и заставить код БД думать, что /run/user/1000/foobar/bazquux — это то же самое, что /mnt/data/path/to/bazquux. Мне кажется, что это случится примерно никогда.

Я не понимаю, что ты пытаешься сказать. Зачем переписывать что-то чтобы заставлять как-то думать?

Вот что мешало монтировать FUSE прямо в то место, где лежит затребованный файл?

просто bind-монтировать файл/каталог с хоста в песочницу вместо

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

Я не понимаю, что ты пытаешься сказать. Зачем переписывать что-то чтобы заставлять как-то думать?

Есть digikam. У него есть своя БД фотографий. В этой БД хранятся полные пути до файлов. Одна и та же БД может использоваться несколькими экземплярами digikam по очереди. Дальше продолжать?

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

Расскажи это авторам nspawn, они по ходу не знают.

Спасибо, пока на форум Flathub написал.

Для DT и GIMP и прочих этот способ подходит, т. к. они работают с отдельными, конкретными файлами пользователя (с прямого ведома и указания пользователя открывается конкретный файл ⇒ приложение с ним работает ⇒ приложение однократно сохраняет результат в тот же файл).

Я крайне плохо разбираюсь в потрохах, но и первому, и второму нужно создавать файлы при экспорте. GIMP-то конкретный файл откроет, если это .xcf, то даже сохранит изменения, но вот создать новый файл не получится. А DT работает и как каталогизатор тоже, поэтому ему тоже нужно просматривать директорию.

Расскажи это авторам nspawn, они по ходу не знают.

Для того, чтобы можно было примонтировать новую ФС к запущенному контейнеру, надо чтобы

1. была точка монтирования с типом распространения shared (как, например, :rshared в докере)
2. у юзера в родительском пространстве имён были права на монтирование

Первое требует видимой из начального пространства имён корневой ФС контейнера, а второе - привилегированного пользователя.

Первое требует видимой из начального пространства имён корневой ФС контейнера

Не вижу проблем так сделать.

а второе - привилегированного пользователя

А как тогда песочница конструируется изначально?

Не вижу проблем так сделать.

Корневая ФС внутри песочницы флатпака - на невидимой снаружи tmpfs. Чтобы сделать её видимой - её надо примонтировать на хосте, т.е. опять же нужны повышенные привилегии.

А как тогда песочница конструируется изначально?

Там, где можно (везде, кроме Дебиана, насколько я знаю) используется unprivileged_userns_clone, чтобы получить повышенные привилегии внутри песочницы, при этом не повышая привилегии на хосте.

Ах вот оно что. То есть они делают непривилегированный clone() в полный набор неймспейсов, включая userns, и настраивают всю ФС песочницу уже изнутри? А что, так можно было? Ну тогда жопа и задача о двух стульях, да.

Такие тонкости работы bubblewrap я знаю плохо, но вроде бы да, он делает clone() дважды - первый в пространство имён, где он подготавливает ФС, а второй уже в итоговое, где будет запущена полезная нагрузка.