TOCTOU

Nil A написал(а) к All в May 23 08:35:06 по местному времени:

* Originally in nino.046.local
* Crossposted in ru.ftn.develop
Нello, All!

Когда-то, в далёкой галактике, году так в 90 каком-то.. никто и не знал про TOCTOU (time-of-check to time-of-use). А я вот сегодня, в 21ом веке мучаюсь, потому что не могу вписать sqpack в крон.

А что если, я сижу в голдеде, пишу свои мемуары, а когда нажимаю отправить, то файл уже удалён, потому что ротейтилка, всмысле, пуржика, его уже стёрла и сделала новый?

Кстати, а под вендой что происходит? Там вроде хер сотрёшь файл, если его кто-то открытым держит? Да, собсна, там и крона то нету, чтобы как-то сильно по этому поводу переживать.

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

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

Здраствуйте, Nil!

Так lock-файлы ж есть.
if(config->lockfile)
{
lock_fd = lockFile(config->lockfile, config->advisoryLock);

if(lock_fd < 0)
{
disposeConfig(config);
exit(EX_CANTCREAT);
}
}
Судя по исходникам, lock только для husky

Не знаю, насколько эти блокировки действенны для редактора (скорее, никак), однако голдед не держит файл базы постоянно открытой - только на время чтения/записи. Открыл, что есть - вписал msg в нужном формате, закрыл.
Так что возможность спуржить sqpack-ом базу прям в момент записи голдеда минимальна.

А для венды nncron был, ЕМНИП. Ну, и планировщик собственный.

Alexey Khromov
--- GoldED+/LNX 1.1.5-b20230304

Cheslav Osanadze написал(а) к Alexey Khromov в May 23 08:43:09 по местному времени:

Привет Alexey!

29 Май 23 23:33, Alexey Khromov -> Nil A:

AK> Судя по исходникам, lock только для husky

AK> Не знаю, насколько эти блокировки действенны для редактора (скорее,
AK> никак), однако голдед не держит файл базы постоянно открытой - только
AK> на время чтения/записи. Открыл, что есть - вписал msg в нужном
AK> формате, закрыл. Так что возможность спуржить sqpack-ом базу прям в
AK> момент записи голдеда минимальна.

AK> А для венды nncron был, ЕМНИП. Ну, и планировщик собственный.

И в "звонилках" фидошных "планировщик" есть. Виндовых.


Cheslav.


... Россия - страна сезонная(Чеpномыpдин)
--- ...

Nil A написал(а) к Alexey Khromov в May 23 11:20:06 по местному времени:

Нello, Alexey!

Monday May 29 2023 23:33, from Alexey Khromov -> Nil A:

AK> Так lock-файлы ж есть.
AK> if(config->lockfile)
AK> {
AK> lock_fd = lockFile(config->lockfile, config->advisoryLock);
AK> if(lock_fd < 0)
AK> {
AK> disposeConfig(config);
AK> exit(EX_CANTCREAT);
AK> }
AK> }
AK> Судя по исходникам, lock только для husky

Это про то, что только одна копия hpt может быть запущена, sqpack тоже часть hpt.
Т.е. пока ты делаешь hpt toss, то sqpack будет ждать.

AK> Не знаю, насколько эти блокировки действенны для редактора (скорее,
AK> никак),

У меня в Хаски написано
> LockFile [FidoSysDir]/flag/hpt-lock
И явно голдед туда не смотрит.

AK> однако голдед не держит файл базы постоянно открытой - только
AK> на время чтения/записи.

Свечку держал? А вот голдед держит, всмысле, файл открытым.

AK> Открыл, что есть - вписал msg в нужном формате, закрыл. Так что
AK> возможность спуржить sqpack-ом базу прям в момент записи голдеда
AK> минимальна.

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

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

Alexey Khromov написал(а) к Nil A в May 23 12:56:06 по местному времени:

Здраствуйте, Nil!

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

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

[fido@fido local]$ lsof -u fido | grep msgbase
gedlnx 525503 fido 4u REG 0,37 256 16234 /var/spool/ftn/msgbase/local/VYBORG.local.sqd
gedlnx 525503 fido 5u REG 0,37 0 16235 /var/spool/ftn/msgbase/local/VYBORG.local.sqi
bash 525766 fido cwd DIR 0,37 534 5581 /var/spool/ftn/msgbase/local
lsof 525833 fido cwd DIR 0,37 534 5581 /var/spool/ftn/msgbase/local
grep 525834 fido cwd DIR 0,37 534 5581 /var/spool/ftn/msgbase/local
lsof 525835 fido cwd DIR 0,37 534 5581 /var/spool/ftn/msgbase/local
[fido@fido local]$

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


Alexey Khromov
--- GoldED+/LNX 1.1.5-b20230304

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

Alexey Khromov написал(а) к Nil A в May 23 18:32:50 по местному времени:

Здраствуйте, Nil!

30 май 23 17:48, Nil A -> Alexey Khromov:

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

Давай исходить из логики данного ПАК:
а) изначально разработан для однозадачных ОС. Фиксилось отдельно в каждом компоненте, а также при разработке новых компонентов взамен старых.
б) каждая часть ПАК (мейлер-тоссер-редактор) должна сохранять независимость от окружения, в том числе от других частей комплекса - в первую очередь поддерживая установленный протокол взаимодействия (в данном случае - файловый).
в) в комплексе заведомо есть недостатки, и "спасение утопающих - дело рук (в первую очередь) самих утопающих".

И мы, в таком случае (когда одна независимая часть комплекса имеет несовместимую процедуру с логикой работы другой части комплекса), скорее всего пишем ERRATA и обходим процедурами, объединяющими этот ПАК (скрипты допиливаем с проверками). Еще можно оценить риски и если он высок (может случится чаще раза в год, например) стучимся с багрепортом, чтобы допиленное страдало меньше.
С учетом давней истории всех проектов и (возможно) сохранения обратной совместимости, пользоваться этим будут особо обеспокоенные любым возможным нештатным поведением сисопы.

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

ЗЫ. /надо было в дранках отвечать/

Alexey Khromov
--- GoldED+/LNX 1.1.5-b20230304

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

Alexey Khromov написал(а) к Nil A в Jun 23 19:18:10 по местному времени:

Здраствуйте, Nil!

02 июн 23 18:15, Nil A -> Semen Panevin:

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

Редактор и тоссер не должны быть взаимозависимы - представь вместо голдеда штатный (для husky) msged.

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

K.I.S.S.
База сообщений - это территория редактора. А возможно, еще и BBS. В любом случае, ЧМИ (для чтения хомосапиенсами).
Тоссер должен быть адаптирован (и он адаптирован, флагами), к наименее конфликтной работе.
Пуржилка относится к инструментам обслуживания. А обслуживаение - это зона повышенного внимания сисопа/админа/босса качалки. Так что сисопу и городить проверку на занятость базы оконечным сапиенсом.

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

Голдеду достаточно в данном случае поставить лок - никто их husky базы не тронет. Но тут другая проблема - пока у тебя открыт голдед, тоссер (и пуржилка, и весь комплект) будет отваливаться "до лучших времен". А сейчас ты можешь заресканить измененную тоссером базу. Пр

Alexey Khromov
--- GoldED+/LNX 1.1.5-b20230304

Nil A написал(а) к Alexey Khromov в Jun 23 19:44:04 по местному времени:

Нello, Alexey!

Friday June 02 2023 19:18, from Alexey Khromov -> Nil A:

AK> Редактор и тоссер не должны быть взаимозависимы - представь вместо
AK> голдеда штатный (для husky) msged.

Взаимозависимость - это когда возможна ситуация дедлока? Вроде бы никому из них нет необходимости держа один лок, при этом ещё хватать другой.

И не важно кто работает с базами, редактор, тоссер, ББС софт. Если необходима операция записи - она должна быть выполнена под локом, чтобы записи в базе не ломались.

AK> K.I.S.S.
AK> База сообщений - это территория редактора. А возможно, еще и BBS. В
AK> любом случае, ЧМИ (для чтения хомосапиенсами). Тоссер должен быть
AK> адаптирован (и он адаптирован, флагами), к наименее конфликтной
AK> работе. Пуржилка относится к инструментам обслуживания. А
AK> обслуживаение - это зона повышенного внимания сисопа/админа/босса
AK> качалки. Так что сисопу и городить проверку на занятость базы
AK> оконечным сапиенсом.

Флаги - это всё костыли. Например, хаски удобно делать свой глобальный лок на любые операции - пускай так делает, никто больше на него не смотрит.
Флаги BSO аутбаунда - более-менее прописаны стандартом, что помогает координироаться тоссеру и мейлеру, а иногда и нескольким мейлерам на одном аутбаунде.
Для баз сообщений флаги не используются (кроме которых с именами эх на импорт и экспорт, чтобы не пробегаться по всем-всем эхам), потому что договорились о блокировке файла средствами ОС.

AK> Голдеду достаточно в данном случае поставить лок - никто их husky базы
AK> не тронет. Но тут другая проблема - пока у тебя открыт голдед, тоссер
AK> (и пуржилка, и весь комплект) будет отваливаться "до лучших времен". А
AK> сейчас ты можешь заресканить измененную тоссером базу. Пр

Так было во времена ДОСа, когда ты сидел в голдеде, потом выходил, всё паковал, и запускал мейлер.
Ну или через какую-то много-задачность запускал мейлер и мог читать в голдеде, но тогда тоссер и упаковка запускалась полувручную.

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