К чему приведет подмена номера inode?

А если мы подменим номер некоторого inode, к чему это мочет привести?

Ни к чему хорошему.

Файлы, inode которых подменили, вообще долго останутся «жить» на ФС?

Походу до fsck, дальше кто-нибудь пострадает.

С какой целью интересуетесь?

С какой целью интересуетесь?

Изучал VFS. Планирую устроить краш-тест ФС.

Ни к чему хорошему.

А можно поточнее?

Я «мимокрокодил» и далеко не специалист, дальше — сугубо мое личное мнение и т.п. Про всякое журналирование и т.п. вообще ничего не знаю...

Но соль во фразе:

А если мы подменим номер некоторого inode?

Проблема в том, что inode естественно, не содержит своего номера, он содержится в какой-то внешней структуре. Тут уже надо знать, что именно она с этим номером ассоциирует и исходя из этого выводить, что именно сломается. «Залезть в inode и поменять ему номер» — такого нет.

Я предполагаю:

1) (Если других хардлинков нету, то) сделает содержимое недоступным, при fsck грохнет и имя, «ссылающееся в мусор»; содержимое, если повезет, пошлет в какой-нибудь lost+found.

2) Будет хардлинк, содержимое: см выше

3) Абсолютно то же, что и 2; файлы внутри: тоже см. выше.

Файлы, inode которых подменили, вообще долго останутся «жить» на ФС?

Фраза настолько туманная, что в ней легко и непринужденно можно потерять трех ежиков и лошадку впридачу. Даже если отставить в сторону вопрос, где именно ты сослался на другой inode и как... и нашу с тобой компетентность... остается тот факт, что у файла есть имя, есть метаданные, есть содержимое, есть черт еще солько всего. Что-то в деревьях, что-то в таблицах, что-то в inod'ах, что-то в extent'ах, что-то черт ногу сломит. Что-то из этого перезапишется сразу, что-то нет, что-то сложится в lost+found, что-то магически починится. Пока нет понимания, о чем ты говоришь, а так же что такое «подменить», «долго», и «жить» — ответом и не пахнет.

Изучал VFS. Планирую устроить краш-тест ФС.

Ну вот ты и ответь на свои вопросы, раз изучал.

В тред призываются спв, включая анонимуса.

Проблема в том, что inode естественно, не содержит своего номера

Насколько я знаю, он, родимый, имеет номер. Какой вид имеет каталог? Список записей, которые включают имя файла и соответствующий ему номер индексного дескриптора. Где же ему быть, как не в inode?)

«Залезть в inode и поменять ему номер» — такого нет.

http://www.opennet.ru/tips/2182_linux_module_kernel_module_inode_fs.shtml. Как-то так.

1) (Если других хардлинков нету, то) сделает содержимое недоступным, при fsck грохнет и имя, «ссылающееся в мусор»; содержимое, если повезет, пошлет в какой-нибудь lost+found.

Хорошо. А допустим, смена номера произошла во время, когда даный дескриптор используется каким-то процессом. Последующие операции от процесса к файлу будут возвращать ошибки или же сам процесс накроется медным тазом (отказ в обслуживании)? Прошу извинить за фантазию, прост и правда интересно ваше мнение)

2) Будет хардлинк, содержимое: см выше

Когда смена произошла во время использования дескриптора процессом, согласен. Но в спокойной ситуации и до проверки fsck-ом - почему? Просто во время поиска файла, процесс подберет первый попавшийся (правда не факт, что нужный) дескриптор и будет делать, что положено. Я так считаю.

3) Абсолютно то же, что и 2; файлы внутри: тоже см. выше.

Тут вроде бы будет зацикление, что по логике приведет к отказу в обслуживании. Ошибаюсь?

Где же ему быть, как не в inode?)

Своем же? Бред. Директории? Нелогично...

1) Не знаю, предполагаю, что все будет ОК.

2) По определению хардлинка.

Просто во время поиска файла, процесс подберет первый попавшийся (правда не факт, что нужный) дескриптор и будет делать, что положено.

Что это такое я сейчас прочитал?

Я так считаю.

У-у.

3) Тут вроде бы будет зацикление

Без двух минут шесть утра, но никаких циклов мне не видится.

1) Не знаю, предполагаю, что все будет ОК.

То есть операция записи в файл, к примеру, пройдет успешно?

Что это такое я сейчас прочитал?

Мои размышления) я же не писал ядро, не могу знать всего. Тут, допустим, процесс имеет... [в этом моменте я понял свою ошибку. Да, тупонул].

Без двух минут шесть утра, но никаких циклов мне не видится.

Отрывок с литературы:

.. Более того, жесткая ссылка может указывать только на файл (жесткая ссылка на каталог может привести к зацикливанию в файловой системе).

Не 100%, но при неких условиях возможно.

Еще такой вопрос: а какими способами можно запретить смену номера inode?

То есть операция записи в файл, к примеру, пройдет успешно?

Не знаю, я не спец.

<цикл при хардлинке на один из каталогов выше по иерархии>

Теперь понял о чем ты. Ну это эффект отдельный от твоих измышлений, скорее всего куда более тщательно расписанный и изученный.

Еще такой вопрос: а какими способами можно запретить смену номера inode?

Ты о чем? Она и так запрещена.

Ты о чем? Она и так запрещена.

Выше я давал ссылку на страницу, где описано создание погружаемого модуля для таких хитростей. Или даная проблема в новых ядрах решена? Можно, конечно, запретить подымать модули, но хочется придумать иное решение.

где описано создание погружаемого модуля

Если у тебя есть права его загрузить, то у тебя есть полный доступ к хосту.

Или даная проблема в новых ядрах решена?

Проблема того, что в ядро можно загрузить модуль? Что он будет выполняться в пространстве ядра?

Можно, конечно, запретить подымать модули, но хочется придумать иное решение.

Их и так запрещено «подымать».

Не неси то, что несешь сейчас, скажи нормально, в чем тебе видится проблема.

в чем тебе видится проблема.

Проблема: запретить смену номера в любом случае. Даже если придется подрихтовать само ядро.

Невозможно. Даже если ты отнимешь возможность напрямую работать с дисковыми устройствами из userspace, перепишешь Linux на микроядро и все ограничишь какими-нибудь правами, все равно можно вшить нужный код в загрузчик или вообще тупо загрузить другую ОС и попортить тебе данные.

Повторяю: что еще за «запретить смену номера в любом случае»?

Повторяю: что еще за «запретить смену номера в любом случае»?

Если злоумышленник каким-то образом получит права суперпользователя, он сможет загрузить любой модуль. С этим не поспоришь. А если мы пройдем в fs.h и в struct inode «unsigned long i_ino» тупо перепишем в «const unsigned long i_ino». Может же сработать?

Пропиши, пересобери мир. Расскажешь,что сломается. «Защиты» от произвольного модуля ядра это никакой не даст, способы «сменить inode» останутся.