TOCTOU

Nil A написал(а) к Stas Mishchenkov в May 23 10:48:14 по местному времени:

* Originally in nino.046.local
* Crossposted in ru.golded
Нello, Stas!

Tuesday May 30 2023 10:13, from Stas Mishchenkov -> Nil A:

NA>> ет. В деде захожу в эху, нажимаю написать письмо, долго-долго
NA>> пишу, при этом из кронтаба пуржилка тот файл базы стирает и
NA>> делает новый. Я заканчиваю письмо, нажимаю отправить, дед файл
NA>> дописывает, закрывает, и кернел эту иноду выносит с файловой
NA>> системы, т.к. больше никто на неё не ссылается. Итого, сообщение
NA>> длинное пропадает в удалённом файле.

SM> Хм. У тебя сквиш? Может это его особенность.

Живу в Jam, потому что мой выбор пал на хождение по линкованным сообщениям, а из в сквише только 9.

SM> С ДЖАмом такого не происходит. Впрочем, линуховый дед - странная
SM> штука.

Я про линукс и про джам.

SM> У меня, например, он, свежесобраный, напрочь не видит мессаги в MSG
SM> базе (Opus/FTS-1).

Это мимо кассы. Надо пейсать багрепорт а голдед эху. А то ходют тут всякие, потом калоши пропадают, тьфу, коммитят всякую ересь, потом msg ниоткрываеюца. ;-)

А вот, тебе домашнее задание. Используя бинарный поиск, ну когда ты льва хочешь загнать, ты в-попу-лам каждый раз делишь.. и ты можешь с O(log n) трудностью отыскать тот саммый коммит, который всё поломал.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Nil A написал(а) к Alexey Khromov в May 23 17:48:44 по местному времени:

* Originally in ru.ftn.develop
* Crossposted in ru.golded
Нello, Alexey!

Tuesday May 30 2023 12:56, from Alexey Khromov -> Nil A:

NA>> Вот тебе домашнее задание. Зайди в эху в годеде, нажми новое
NA>> собщение, сотри джам базу (не знаю какой именно файл,
NA>> .jhr/.jdt/.jdx, лениво смотреть по стрейсу или по коду, хедер
NA>> наверное), и запости сообщение - оно запоститься на ура. ОС
NA>> линукс, если что. Потому что под линуксом, как и под другими
NA>> никсами, можно прям стереть файл, и df не покажет, что место уже
NA>> освободилось, кернел потом освободит, как на иноду больше никто
NA>> ссылаться не будет.

AK> Базу удалил, голдед не отрыгнув записал мессагу в файл, которого
AK> больше нет, при открытии повторно эхи - пересоздал эху.

Спасибо, что проверил. Репродуцировать эту ситуацию действительно легко.

AK> проверить, что файло открыто достаточно легко:
AK> [fido@fido local]$ lsof -u fido | grep msgbase
AK> соответственно и пурджить можно проверяя, не открыт ли файл) если уж
AK> совсем пытаться все предусмотреть.

Я начал тред именно с того, что вот такие вот решения и являются TOCTOU. Ты сначала проверишь, а потом пойдёшь пуржить или нет? ;-)

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Semen Panevin написал(а) к Nil A в May 23 08:07:02 по местному времени:

Доброго здоровьица тебе, Nil!

Tuesday May 30 2023 17:48, Nil A писал Alexey Khromov:

AK>> проверить, что файло открыто достаточно легко:
AK>> [fido@fido local]$ lsof -u fido | grep msgbase
AK>> соответственно и пурджить можно проверяя, не открыт ли файл) если
AK>> уж совсем пытаться все предусмотреть.

NA> Я начал тред именно с того, что вот такие вот решения и являются
NA> TOCTOU. Ты сначала проверишь, а потом пойдёшь пуржить или нет? ;-)

Казалось бы, причём тут голдед? Пуржит-то по идее не он, а утилиты из комплекта тоссера?

С наилучшими пожеланиями, Семён.

... Без крыльев далеко не улетишь
--- GoldED+/LNX 1.1.5-b20220504 (Linux 5.15.52-gentoo iF6M10)

Nil A написал(а) к Semen Panevin в Jun 23 18:15:58 по местному времени:

* Originally in ru.golded
* Crossposted in ru.ftn.develop
Нello, Semen!

Wednesday May 31 2023 08:07, from Semen Panevin -> Nil A:

AK>>> проверить, что файло открыто достаточно легко:
AK>>> [fido@fido local]$ lsof -u fido | grep msgbase
AK>>> соответственно и пурджить можно проверяя, не открыт ли файл)
AK>>> если уж совсем пытаться все предусмотреть.

NA>> Я начал тред именно с того, что вот такие вот решения и являются
NA>> TOCTOU. Ты сначала проверишь, а потом пойдёшь пуржить или нет?
NA>> ;-)

SP> Казалось бы, причём тут голдед? Пуржит-то по идее не он, а утилиты из
SP> комплекта тоссера?

У меня есть идея, как можно починить именно голдед тут.

Пуржилка хватает лок на базу при своей работе, т.е. если в этот момент голдед бы держал лок, то пуржилка бы ждала. Но не комельфо всю дорогу держать лок на базу, поэтому голдед делает всё правильно, он открыл файлы баз, читает из них, а когда надо записать, он коротко берёт лок.

Сейчас проблема в юниксовом голдеде (линукс, фрибсд, макось, ..) в том, что он берёт лок на базу удачно, записывает сообщение, но потом оказывается, что это уже было на удалённом файле.

Моё предложение - голдед хватает лок, далее делает fstat() на этот открытый файл, проверяет поле st_nlink, и если там ноль, значит этот файл уже стёрли, значит надо переоткрыть файл. При этом тут TOCTOU не проиходит, потому что сначала успешно схвачен лок, а потом уже спокойно проверяется, не стёрт ли файл.

Best Regards, Nil
--- GoldED+/LNX 1.1.5