mirror of
https://github.com/Nekrolm/ubbook.git
synced 2025-12-18 05:14:34 +03:00
63 lines
6.0 KiB
Markdown
63 lines
6.0 KiB
Markdown
# Конкурентный доступ к файловой системе
|
||
|
||
Условия гонки за ресурсы могут возникать на разных уровнях:
|
||
- внутри одной программы
|
||
- между несколькими программами на одном компьютере
|
||
- между разными программами на разных компьютерах
|
||
|
||
И почти всегда это нежелательная, ошибочная ситуация, последствия которой варьируются от просто неправильного результата до чудовищных уязвимостей в безопасности.
|
||
|
||
Иногда, конечно, система может быть толерантна к таким ошибкам и серьезных проблем не возникнет: например, если страничка магазина запрашивает список товаров на складе, а в этот момент база данных склада обновляется, то вы, как пользователь, возможно, увидите неполный или устаревший список товаров или смесь из старых и новых данных. Но критического ничего не произойдет, если разработчики предусмотрели дополнительные проверки с запросом к базе данных в момент взаимодействия с конкретным товаром из списка... Чтобы вы не купили то, чего больше не существует.
|
||
|
||
Файловая система — один из таких ресурсов, гонки за которым естественны и должны учитываться при разработке приложений. Да, самые низкоуровневые проблемы синхронизации чтения и записи в файловую систему берет на себя операционная система и (или) конкретный драйвер. Можно «спокойно» одновременно из разных процессов читать и писать в один и тот же файл и получать мусор или штатные ошибки: низкоуровневые операции `read` и `write` будут как-то упорядочены планировщиком ввода-вывода. С самой файловой системой при этом всё будет в порядке.
|
||
|
||
Но высокоуровневые операции над файловой системой в рамках вашей бизнес-логики требуют внимания и осторожности. Ведь самый простой способ получить условие гонки — добавить проверки при открытии файла!
|
||
|
||
```C++
|
||
#include <filesystem>
|
||
#include <string>
|
||
#include <fstream>
|
||
|
||
namespace fs = std::filesystem;
|
||
|
||
int main() {
|
||
if (!fs::exists("/my/file")) {
|
||
return EXIT_FAILURE;
|
||
}
|
||
std::ifstream input("/my/file");
|
||
std::string line; input >> line;
|
||
// do something
|
||
return EXIT_SUCCESS;
|
||
}
|
||
```
|
||
|
||
Это класcическая **TOCTOU** (*Time-of-Check-Time-of-Use*) ошибка. Между проверкой и открытием файла, файл может быть удален.
|
||
|
||
Но причем тут С++, если такая проблема существует для любого языка программирования?
|
||
|
||
Действительно. Например, во всех версиях стандартной библиотеки Rust с 1.0 до 1.58.1 [была](https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) похожая ошибка в реализации функции `remove_dir_all`.
|
||
|
||
```Rust
|
||
// это упрощенный код
|
||
// directory: Path
|
||
if directory.is_symlink() {
|
||
remove_link(directory)
|
||
} else {
|
||
remove_recursive(directory)
|
||
}
|
||
```
|
||
|
||
Между проверкой и удалением злоумышленник мог подменить настоящий каталог на символьную ссылку и добиться удаления данных, к которым у него нет доступа.
|
||
|
||
Ошибку исправили: вместо работы с путями, функция стала работать с элементами в каталоге через единожды открытываемый файловый дескриптор.
|
||
|
||
А теперь мы можем вернуться к C++:
|
||
|
||
В std::filesystem также есть функция `remove_all`, с тем же значением что и версия из Rust. И в большинстве ее реализаций в 2022 году также нашли точно такую же [ошибку](https://issuetracker.google.com/issues/42410010?pli=1)!
|
||
|
||
Обсуждение этой ошибки было довольно [бурным](https://www.reddit.com/r/cpp/comments/s8ok0h/possible_toctou_vulnerabilities_in/), поскольку стандарт C++ объявляет неопределенным поведением любые вызовы функций std::filesystem, приводящие к гонке!
|
||
|
||
Но они все приводят к гонке! Их корректная работа зависит только от благонадежности других приложений, обращающихся к той же файловой системе. Можно ли в таком случае ничего не исправлять в функции `std::filesystem::remove_all`?
|
||
|
||
Конечно нужно! Ошибка была исправлена в GCC версии [11.5](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161) и в [Clang-14](https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf)
|