On Fri, Jan 16, 2015 at 10:07:57PM +0300, Anton Farygin wrote:
> On 16.01.2015 17:54, Dmitry V. Levin wrote:
> >On Tue, Jan 13, 2015 at 02:55:13PM +0300, Anton Farygin wrote:
> >>On 12.01.2015 22:36, Dmitry V. Levin wrote:
> >[...]
> >>>Там возникнет конфликт прав доступа к
> >>>chroot/dev/shm, который еще надо
> >>>придумать, как разрешить:
> >>>- если chroot/dev/shm уже на tmpfs, то
> >>>псевдопользователь #2 должен иметь
> >>>доступ к нему на запись;
> >>
> >>А чем тебя не устраивает 777 на chroot/dev/shm ?
> >
> >Там сейчас 1777, и это устраивало всех, 
> >кроме процедуры монтирования.
> >
> >>>- если chroot/dev/shm должен быть смонтирован,
> >>>то на права доступа к нему
> >>>налагаются сильные ограничения.
> >
> >Я почти убедился в том, что в режиме mount 
> >namespace isolation права
> >доступа 1777 новых угроз не создают.
> >
> >Интересно, сколько nr_blocks и nr_inodes 
> >необходимо давать для /dev/shm
> >в чруте по умолчанию?
> 
> Это не имеет никакого значения

Речь идет об умолчаниях, которые будут зашиты в hasher-priv/mount.c

> - сейчас 
> ты даёшь на сборочнице явно больше, чем 
> любое ограничение.

Сборочница тут вообще не при чем: все сборочные узлы бездисковые,
там все на tmpfs, и /dev/shm там монтировать незачем.

> Кстати, что будет на сборочнице, если 
> некий пакет случайно создаст очень много 
> мусора в /dev/shm в сборочном чруте ?

Сборочнице все равно, где пакет размещает свой мусор.
У каждого сборочного потока действует свой memory.limit_in_bytes.

> Это же можно и сейчас проверить ?

Да проверяли уже.
http://lists.altlinux.org/pipermail/devel/2014-September/199034.html
http://lists.altlinux.org/pipermail/devel/2014-September/199054.html


-- 
ldv