path of the opened fd [message #51553] |
Fri, 18 July 2014 19:03 |
|
Может кто подскажет, как ядро получает путь (полное имя) файла, имея на руках открытый программой файловый дескриптор? В частности эту процедуру выполняет в ядре 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 |
|
Проблема с 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 |
|
Проблему с использованием 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 |
|
Использование 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, который в действительности читается (из ветки).
|
|
|