История изменений

Не делай так, во-первых это создаст проблемы с разрешением unix путей в dos, во вторых не уберёт доступа в корень - он всё ещё будет дрст4пен другими путями.
Используй контейнеризацию, например, steam runtime с pressure-vessel кониейнером, она сейчас рекомендуется для игр т.к позволяет использовать системные драйвера и не создавать им конфликты зависимостей, а так же избежать хранения нескольких разных версий библиотеки в памяти если в системе библиотека новее.
Можно что-тотаналогичное сделать вручную, например unshare -u запустит shell в user namespace с фейковым рутом, замаппленным на твоего юзера. Внутри можно сделать chroot, тем самым ограничив досиуп к ФС и уже внутри него setuid на непривелигированного пользователя. Так кониейнеры и работают. После setuid процесс уже не может выбраться из chroot.
Так же unshare -p скрывает хостовые процессы и делают создаваемый процесс инитом в новом контейнере, unshare -m отвязывает дерево монтирования, что позволяет монтировать в контейнере ФС незаметно для хоста.
Чтобы сделать chroot - нужно создать «клон» хостовой системы с теми файлами которые нужны для работы протона, но тебе при этом не жалко показывать их запускаемому в нём софту. Например, можно пробросить /etc, /usr, и прочее с -o bind, а так же всё нужное chroot'у: /dev, /dev/pts, /proc, /run например
Некоторые контейнеры вместо этго делают копию или вообще свой дистр с библиотеками нужных версий.
Стимовский контейнер делает хитрее - он сравнивает версии библиотек и подсовывает те, что новее. Т.к библиотеки должны быть обратно совместимыми - это позволяет получить наиболее универсальный контейнер. fatpak вместо этого тащит целиком другой дистр, причём каждый раз разных версий под разные приложения. Результат - беги за новым диском и оперативкой побольше. Забавно, но из-за этого дебианщики очень любят fatpak, ведь если у них в дебиане что-то не работает из-за древних версий - fatpak притащит с собой рабочий софт

Не делай так, во-первых это создаст проблемы с разрешением unix путей в dos, во вторых не уберёт доступа в корень - он всё ещё будет дрст4пен другими путями.
Используй контейнеризацию, например, steam runtime с pressure-vessel кониейнером, она сейчас рекомендуется для игр т.к позволяет использовать системные драйвера и не создавать им конфликты зависимостей, а так же избежать хранения нескольких разных версий библиотеки в памяти если в системе библиотека новее.
Можно что-тотаналогичное сделать вручную, например unshare -u запустит shell в user namespace с фейковым рутом, замаппленным на твоего юзера. Внутри можно сделать chroot, тем самым ограничив досиуп к ФС и уже внутри него setuid на непривелигированного пользователя. Так кониейнеры и работают. После setuid процесс уже не может выбраться из chroot.
Так же unshare -p скрывает хостовые процессы и делают создаваемый процесс инитом в новом контейнере, unshare -m отвязывает дерево монтирования, что позволяет монтировать в контейнере ФС.
Чтобы сделать chroot - нужно создать «клон» хостовой системы с теми файлами которые нужны для работы протона, но тебе при этом не жалко показывать их запускаемому в нём софту. Например, можно пробросить /etc, /usr, и прочее с -o bind, а так же всё нужное chroot'у: /dev, /dev/pts, /proc, /run например
Некоторые контейнеры вместо этго делают копию или вообще свой дистр с библиотеками нужных версий.
Стимовский контейнер делает хитрее - он сравнивает версии библиотек и подсовывает те, что новее. Т.к библиотеки должны быть обратно совместимыми - это позволяет получить наиболее универсальный контейнер. fatpak вместо этого тащит целиком другой дистр, причём каждый раз разных версий под разные приложения. Результат - беги за новым диском и оперативкой побольше. Забавно, но из-за этого дебианщики очень любят fatpak, ведь если у них в дебиане что-то не работает из-за древних версий - fatpak притащит с собой рабочий софт