В докере можно указать юзера и группу: --user `id -u`:`id -g` Можно

ли как-то в compose.yaml аналогичное сделать без левых хаков типа определения новых переменных окружения перед запуском композа?

Нет

Зачем запускать контейнер от id хостового юзера? Оо

При билде можно user указать, https://stackoverflow.com/questions/48727548/how-to-configure-docker-compose-yml-to-up-a-container-as-root

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

Вопрос про проброс id пользователя с хоста в docker-compose.yml не через переменные окружения. Такого варианта просто нет

Что мешает этой папке выдать нужные права то? Ну, как по всем канонам

Ну дал ты ей права 777, приложение в контейнере запущено под рутом, и создаёт файлы с владельцем root. Без sudo на хосте ты с этими файлами ничего сделать не можешь, т.к. не являешься их владельцем

Што? Нет? С 777 ты можешь чо угодно делать

Это если ты выдал права на уже существующие файлы. А если они создаются кем-то другим в этой папке ПОСЛЕ выдачи на нее прав, то при создании можно указать любые права (они из папки не наследуются), и на это далеко не всегда можно повлиять. Например, права могут быть захардкожены в коде приложения

Можно не пускать контейнеры от рута, ваш кэп Запуск контейнера от юзера из id приведет лишь к тому, что другой челик с правами к докеру но без прав на чтение твоих файлов не сможет прочитать эти файлы и не сможет нормально ребутнуть контейнер. Нафига так делать то? Что мешает создать нужного юзера в системе?

Тем, что ради запуска контейнера ты вмешиваешься в окружение хоста. Это странно, по меньшей мере

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

Чтобы пробросить bind mount, в котором контейнер будет работать с файлами с нужными правами.

Ага, но такой образ будет жестко привязан к той машине, где его билдили.

setfacl? Как по мне - костыль

Ну имхо сильно проще просто выдать права на папку юзеру из под которого пускаешь

Chmod

Он только в прошлое работает. Если контейнер что-то изменит снова, то у юзера будут ошибки. Вот вариант на будущее - setfacl Создавать новую группу с фиксированным айдишником и добавлять в неё юзера - тоже костыль.

Вот, все верно)

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

Нет, выдать права на папку уиду из под которого пускается контейнер Захардкодить уид внутри докерфайла

Кстати недавно я когда настраивал autofs, столкнулся с приколом, что с юзером root и правами 777 на файл я не мог никак взаимодействовать. Тупо permission denied

Ну то есть заводить отдельного пользователя в системе еще с определенным уидом?) Как мо мне еще костыльнее других вариантов

Нет, зачем

Ацлки какие-то небось ещё, или приколы фс