[devel] Убрать /etc/mtab -> /proc/mounts [was: количество смонтированных устройств]

[Dmitry V. Levin]

On Tue, Jan 31, 2012 at 01:09:25AM +0400, Alexey Gladkov wrote:
> Чем бы не был /etc/mtab ссылкой или файлом мне кажется ошибочным
> надеяться на mount -n т.к. если какая-то "неправильная" программа
> воспользуется mount --bind без -n, то у вас будут опять проблемы.
> Правильнее фильтровать нужные каталоги.

Тут, насколько я понимаю, речь идет о вполне конкретной конфигурации:
ovz-сервер, в котором vzctl start всегда делает "mount -n", и раньше
это работало лучше с точки зрения вывода "mount", чем сейчас.
Считается, что в HN ovz-сервера программ мало, и "неправильных" среди
них нет. :)

> Что будет если в контейнере сделать mount --bind без использования
> namespace ?

Если в ovz-контейнере сделать mount без использования namespace и всяких
там MS_*, то в корневом /proc/mounts появится соответствующая запись.
В корневом /etc/mtab она, разумеется, не появится в случае если это
обычный файл а не ссылка на /proc/mounts.

> > Никто не против того, чтобы делать ссылку тогда когда это нужно. Если 
> > для systemd, livecd или внутри VPS нужна ссылка, то конечно пусть будет. 
> 
> Изменение файл <-> симлинк в rpm очень неприятное занятие.

Не особенно, в отличие от "каталог" <-> "ссылка на каталог".

> Можно сделать control, но это не позволит перезаполнить /etc/mtab при
> переключении симлинк -> файл. Так что это будет дистрибутивная полумера.

Тем не менее можно придумать какой-нибудь приемлемый opt-out.
Например, запаковать /etc/mtab не просто как ссылку на /proc/mounts, а с
атрибутом %ghost; в %post создавать настоящую ссылку, если /etc/mtab еще
нет.  Тогда админ сможет изменить поведение по умолчанию, превратив
вручную /etc/mtab из ссылки в обычный файл, заполнив его на свое
усмотрение.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20120131/e1adb50b/attachment.bin>