Можно ли внутри chroot понизить права до обычного пользователя?

необходимые файлы (/etc/passwd)

А так же библиотеки, /etc/shadow и остальное.
Если в чруте полный вариант ОС (без ядра само собой) - то получится без лишний телодвижений.

эм... да. Никогда не копировал в чрут пользвателей, но если их в чруте создать, то можно и понизить

А так же библиотеки, /etc/shadow и остальное.
Если в чруте полный вариант ОС (без ядра само собой) - то получится без лишний телодвижений.

То есть нужно сделать mount --bind каталогов /etc /lib /bin и /sbin и /dev ?

http://ru.wikipedia.org/wiki/Mount#mount_--bind

--userspec=USER:GROUP. И man chroot, наконец!

То есть нужно сделать mount --bind каталогов /etc /lib /bin и /sbin и /dev ?

А что вы тогда пытаетесь защитить chroot'ом? Похоже /home

Посмотри на schroot, я пользуюсь и мне нравится :-)

Description-en: Execute commands in a chroot environment
 schroot allows users to execute commands or interactive shells in
 different chroots.  Any number of named chroots may be created, and
 access permissions given to each, including root access for normal
 users, on a per-user or per-group basis.  Additionally, schroot can
 switch to a different user in the chroot, using PAM for
 authentication and authorisation.  All operations are logged for
 security.
 .
 Several different types of chroot are supported, including normal
 directories in the filesystem, and also block devices.  Sessions,
 persistent chroots created on the fly from files (tar with optional
 compression) and Btrfs and LVM snapshots are also supported.
 .
 schroot supports kernel personalities, allowing the programs run
 inside the chroot to have a different personality.  For example,
 running 32-bit chroots on 64-bit systems, or even running binaries
 from alternative operating systems such as SVR4 or Xenix.
 .
 schroot also integrates with sbuild, to allow building packages with
 all supported chroot types, including session-managed chroot types
 such as Btrfs and LVM snapshots.
 .
 schroot shares most of its options with dchroot, but offers vastly
 more functionality.

Еще может вместо chroot ты захочешь использовать lxc

Как быстрый вариант - недавно решал задачу запуска жирного проприетарного приложения с кучей зависимостей под 32 бита в 64 битном арче. Проще всего показалось накатить debian-minimal на виртуалку, потом из виртуалки вытащил рекурсивно всю инсталляцию в /opt/debian32 . Аппликейшн запускаю так:

for i in /sys /dev /proc ; do mount --bind $i /opt/debian32${i}; done 
chroot /opt/debian32 /bin/bash
su - user
/opt/proprietary/application

Проще всего показалось накатить debian-minimal на виртуалку, потом из виртуалки вытащил рекурсивно всю инсталляцию в /opt/debian32

Тоже самое можно было сделать при помощи одной команды

lxc-create -t debian -n debchroot

А что вы тогда пытаетесь защитить chroot'ом? Похоже /home

Да. Ты угадал.

Если в арче, то посмотри на arch-chroot из пакета arch-install-scripts.

А не проще ли запускать приложение без chroot из под юзера не имеющего доступ к /home?

А не проще ли запускать приложение без chroot из под юзера не имеющего доступ к /home?

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

А зачем? Обычно предполагается, что в чруте у тебя один пользователь. Ну и пусть он будет рутом.

А зачем? Обычно предполагается, что в чруте у тебя один пользователь. Ну и пусть он будет рутом.

Но ведь /dev и /var таки придётся ему дать.

Что значит можно? Нужно! Иначе смысла нет.

Один из примеров вызова gmrun

/usr/bin/sudo /usr/sbin/chroot /path/to/chroot/ /usr/bin/sudo -u someuser -H /usr/bin/gmrun >/dev/null 2>&1 &

Либо вводить пароль на sudo, либо дать себе привилегии только на /usr/sbin/chroot.

У меня в обиходе только:

mount -t proc proc /path/to/proc
mount -t devpts devpts /path/to/dev/pts

То есть нужно сделать mount --bind каталогов /etc /lib /bin и /sbin и /dev ?

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

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

Цель, запуск различных приложений, главным образом использующих OpenGL. Нужно что бы программы точно работали. Но потенциально любая из них в случае если будет заражена трояном или каким нибудь другим вирусом, не могла как украсть данные пользователя из его настоящего ~/ , так и не могла повредить системные файлы.