Может кто подскажет, как ядро получает путь (полное имя) файла, имея на руках открытый программой файловый дескриптор? В частности эту процедуру выполняет в ядре 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...
Проблема с suspend/resume при использовании aufs для fs CT, как оказалось, вызвана тем, что SUSPEND рассматривает файловые дескриторы, открытые ядром, как пользовательские. Это, вообще-то, не правильно. Файловые дескприторы ядра НЕ надо сохранять/восстанавливать. Попробую написать BugZillu
Проблему с использованием aufs для /vz/private/XXX и чтоб suspend/restore работал решил с помощью fusefs-bind (bindfs). То есть каталог с файловой системой aufs привязывается к /vz/private/XXX с помощью fuse-программы bindfs. По эффекту -- это аналог команды 'mount -o bind'. Но suspend/resume начинает работать в отличии от 'mount -o bind'.
Использование 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, который в действительности читается (из ветки).