OpenVZ Forum


Home » International » Russian » path of the opened fd (escape from docker ct, bind mount)
path of the opened fd [message #51553] Fri, 18 July 2014 19:03 Go to next message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: 83.220.237*
Может кто подскажет, как ядро получает путь (полное имя) файла, имея на руках открытый программой файловый дескриптор? В частности эту процедуру выполняет в ядре checkpoint/restore, запомимая путь (имя) открытого программой файлового дескриптора при suspend и открывая по запомненому имени fd при resume.

Озаботился данной проблемой при попытке использования для CT aufs и отказе openvz выполнять suspend/resume. Выяснилось, что полное имя файла в этом случае -- это оригинальное имя файла. То есть открытый программой fd ссылается на оригинальный dnode (вне aufs).

Проблема не является специфичной для aufs. Недавний эксплоит для docker, который позволял программе из контейнера открыть любой файл из host-системы базировался на том, что часть файлов внутри контейнера была смонтирована по "mount -o bind". Эксплоит открывал такой файл и с помошью этого дескриптора получал доступ к файловой системе хоста. Этот файловый дескриптор каким-то образом ссылается на оригинальный dnode.

Конечная задача -- это понять: возможно ли реализовать kernel mode unionfs, в которой файловый дескриптор (открытый программой файл) не ссылается на оригинальный dnode?

PS: подозреваю, что в fd нет прямой ссылки на dnode...
Re: path of the opened fd [message #51554 is a reply to message #51553] Sat, 19 July 2014 14:38 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: 83.220.236*
Проблема с suspend/resume при использовании aufs для fs CT, как оказалось, вызвана тем, что SUSPEND рассматривает файловые дескриторы, открытые ядром, как пользовательские. Это, вообще-то, не правильно. Файловые дескприторы ядра НЕ надо сохранять/восстанавливать. Попробую написать BugZillu
Re: path of the opened fd [message #51764 is a reply to message #51554] Thu, 13 November 2014 03:06 Go to previous messageGo to next message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: 83.220.237*
Проблему с использованием aufs для /vz/private/XXX и чтоб suspend/restore работал решил с помощью fusefs-bind (bindfs). То есть каталог с файловой системой aufs привязывается к /vz/private/XXX с помощью fuse-программы bindfs. По эффекту -- это аналог команды 'mount -o bind'. Но suspend/resume начинает работать в отличии от 'mount -o bind'.

[Updated on: Thu, 13 November 2014 03:45]

Report message to a moderator

Re: path of the opened fd [message #51788 is a reply to message #51764] Tue, 09 December 2014 17:01 Go to previous message
seyko2 is currently offline  seyko2
Messages: 184
Registered: February 2007
Location: Moscow
Senior Member

From: 83.220.239*
Использование bindfs (fuse) для получения возможности сделать suspend-resume для контейнера, расположенного на aufs, не очень хорошо. Это лишний шаг, дополнительные глюки и тормоза.

Путём модификации kernel/cpt/cpt_mm.c в части использования vma->vm_prfile вместо vma->vm_file если vma->vm_prfile != 0 добился работы suspemd-resume без дополнительных костылей.

Поле vm_prfile в структуру vma_area_struct добавяется aufs-патчем. aufs в этом поле хранит оригинальный vm_file. А поле vm_file в результате хранит file, который в действительности читается (из ветки).
Previous Topic: current tty as console in CT
Next Topic: Доступ к диску в OpenVZ
Goto Forum:
  


Current Time: Sat Oct 21 21:26:39 GMT 2017