Все началось с того, что друг показал удивительный артефакт: на флешке в одном каталоге было два файла с идентичным названием. Разгадка, конечно, простая: во всем виноват фотоаппарат, у которого, возможно, меньше проверок в момент записи кадра.
Этот прецедент побудил поискать ответы на несколько вопросов. Можно ли обмануть операционную систему компьютера и нарушить запреты файловых систем? И если это получится, то как отреагирует ОС?
Под катом вас ждет небольшой экскурс в особенности работы файловых систем и набор экспериментов.
Большинство ограничений на имена файлов и каталогов очевидны.
- Длина имени файла ограничена. Структура, которая хранит информацию о файле не бесконечна.
- Длина абсолютного пути до файла ограничена. Чуть менее очевидно, но причина идентична: размер буфера, в котором хранится абсолютный путь до файла, тоже не бесконечен.
- Разделитель в пути, символ «/», использовать нельзя.
- Нуль-символ использовать нельзя — это признак конца строки.
- Внутри одного каталога не может быть двух файлов с одним именем.
Переполнять имена файлов — не так интересно, потому что обычно размер полей прописан отдельным целочисленным полем. Если его переполнить, структура потеряет целостность. А вот добавить в имя разделитель или сделать два файла с одним именем… Уже догадываетесь?
Все есть файл
В семействе операционных систем *NIX есть красивая идея, которая описывается словами «Everything is a file», то есть «все есть файл». Благодаря этой абстракции практически все операции ввода-вывода используют один интерфейс, состоящий из следующих системных вызовов. Это не полный список.
- open(2) — открытие ресурса на чтение или запись.
- read(2) — чтение байтов из ресурса.
- write(2) — запись байтов в ресурс.
- close(2) — закрытие ресурса.
Пионеры компьютерных наук — это умные люди, которые решали невиданные ранее задачи. Это великое наследие, к которому иногда возникают вопросы. Например, почему системный вызов для создания файла называется creat(2), а не create(2)? Маленькие познавательные тексты и рассуждения по темам будущих статей — в моем Telegram-канале.
Эти вызовы позволяют получать доступ практически ко всем ресурсам в операционной системе.
- К отдельным файлам и каталогам, которые лежат на накопителе.
- Непосредственно к байтовому представлению на накопителе (файлы /dev/sd* и /dev/nvme*).
- К внешнему устройству: принтеру, мышке, клавиатуре (файлы /dev/input/, /dev/mouse*).
- Даже сокеты Беркли, которые используются для доступа в Интернет, поддерживают перечисленные операции. Только открытие происходит с помощью системного вызова socket(2), а не через open(2).
Но не будет погружаться на всю глубину этой абстракции, взглянем в самое начало. Каталог — это тоже файл. Да, его можно прочитать утилитой cat. Но не в современных системах.
root@ubuntu-2204:~# cat /tmp
cat: /tmp: Is a directory
root@ubuntu-2204:~#
В Linux этот фокус не работает, а вот во FreeBSD до 12 версии можно вывести каталог.
root@freebsd-11:~ # cat /tmp
X...X .X11-unix<X .XIM-unix<X .ICE-unix<X
PERL5_DEFAULTlocal.UgDju9Hnodmail.RsZJCJr4Yt6Hmail.RsygwgsVOYB4(write-422194.oZxxhash-737aeb.oZbench-fb2faf.lz4io-a10809.olz4cli-b2a9d6.o
root@freebsd:~ #
Вывод — это не просто набор непечатных символов и имен файлов, а текстовое представление содержимого каталога. Каталог — это массив структур dirent, который выглядит следующим образом:
struct dirent {
__uint32_t d_fileno; /* file number of entry */
__uint16_t d_reclen; /* length of this record */
__uint8_t d_type; /* file type, see below */
__uint8_t d_namlen; /* length of string in d_name */
#ifdef _POSIX_SOURCE
char d_name[255 + 1]; /* name must be no longer than this */
#else
#define MAXNAMLEN 255
char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */
#endif
};
Для чтения каталогов есть отдельные функции, которые разбирают содержимое каталога на структуры dirent: opendir(3), readdir(3) и closedir(3). Но в академических целях можно обойтись без них:
#include <stdio.h> // printf(3)
#include <sys/types.h> // open(2)
#include <sys/stat.h> // open(2)
#include <fcntl.h> // open(2)
#include <errno.h> // errno
#include <string.h> // strerror(3)
#include <unistd.h> // close(2)
#include <dirent.h>
#define BUF_SIZE 4096
int main(int argc, char* argv[])
{
// Открываем на чтение. Без флага O_DIRECTORY будет ошибка.
int fd = open(argv[1], O_DIRECTORY | O_RDONLY);
if(fd < 0) {
printf("Cannot open %s: %sn", argv[1], strerror(errno));
return 1;
}
unsigned char buf[BUF_SIZE];
while(1) {
struct dirent dir;
/* Считываем по одному полю */
ssize_t count = read(fd, &dir.d_fileno, sizeof(dir.d_fileno));
/* Обработка ошибок один раз для читаемости */
if(count < 0) {
printf("Read error: %sn", strerror(errno));
return 2;
}
if(count == 0) break;
count += read(fd, &dir.d_reclen, sizeof(dir.d_reclen));
count += read(fd, &dir.d_type, sizeof(dir.d_type));
count += read(fd, &dir.d_namlen, sizeof(dir.d_namlen));
count += read(fd, &dir.d_name, dir.d_reclen - count);
dir.d_name[dir.d_namlen] = '';
printf("Entry:n");
printf("td_fileno: %un", dir.d_fileno);
printf("td_reclen: %u (read: %zd)n", dir.d_reclen, count);
printf("td_type: %un", dir.d_type);
printf("td_namelen: %un", dir.d_namlen);
printf("td_name: %sn", dir.d_name);
}
close(fd);
return 0;
}
Да, это тоже работает:
root@freebsd:~ # ./a.out /tmp
Entry:
d_fileno: 11556864
d_reclen: 12 (read: 12)
d_type: 4
d_namelen: 1
d_name: .
Entry:
d_fileno: 2
d_reclen: 12 (read: 12)
d_type: 4
d_namelen: 2
d_name: ..
Entry:
d_fileno: 11556869
d_reclen: 20 (read: 20)
d_type: 4
d_namelen: 9
d_name: .X11-unix
Entry:
d_fileno: 11556870
d_reclen: 20 (read: 20)
d_type: 4
d_namelen: 9
d_name: .XIM-unix
Entry:
d_fileno: 11556871
d_reclen: 20 (read: 20)
d_type: 4
d_namelen: 9
d_name: .ICE-unix
Entry:
d_fileno: 11556872
d_reclen: 20 (read: 20)
d_type: 4
d_namelen: 10
d_name: .font-unix
Entry:
d_fileno: 11556915
d_reclen: 408 (read: 408)
d_type: 8
d_namelen: 13
d_name: PERL5_DEFAULT
Кстати, в функциях для работы с директориями нет ничего про запись. Но раз у нас есть общий интерфейс, то попробуем открыть директорию на запись и что-нибудь сломать.
#include <stdio.h> // printf(3)
#include <sys/types.h> // open(2)
#include <sys/stat.h> // open(2)
#include <fcntl.h> // open(2)
#include <errno.h> // errno
#include <string.h> // strerror(3)
#include <unistd.h> // close(2)
int main(int argc, char* argv[])
{
/* Сперва откроем на запись, вдруг прокатит */
int fd = open(argv[1], O_DIRECTORY | O_WRONLY);
if(fd < 0) {
printf("Cannot open for write %s: %sn", argv[1], strerror(errno));
return 1;
}
return 0;
}
Компилируем, запускаем.
root@freebsd:~ # cc write.c
root@freebsd:~ # ./a.out /tmp
Cannot open for write /tmp: Is a directory
root@freebsd:~ #
Не получилось. Я проверял этот код на FreeBSD 11, которая вышла в 2016 году. Может, в каноническом UNIX нет таких ограничений? Перепишем код в синтаксис K&R. Константы O_WRONLY тоже нет, поэтому заглядываем в документацию и выбираем число 1.
int main(argc, argv)
int argc;
char* argv[];
{
int fd;
fd = open(argv[1], 1);
if(fd < 0) perror("open");
return 0;
}
И запустим. Для проверки таких гипотез можно использовать эмулятор PDP-11/70 на JavaScript, который доступен в браузере. Он также содержит образы Unix v5 и BSD2.11. Запустим код на Unix v5.
# cc a.c
# ./a.out /tmp
open: Is a directory
Это было ожидаемо. Более того, попытки поискать что-то похожее на структуру dirent на накопителе не увенчаются успехом. Структура dirent — это абстракция, независимая от используемой файловой системы. Ядро «подкладывает» подобные структуры при запросе, поэтому записать в них ничего нельзя.
Хорошо, мы не можем из пространства пользователя изменить содержимое каталога. Тогда замыслим шалость!
Не доверяй пользовательским данным
Если мы не можем через операционную систему ввести некорректные данные, значит, мы сделаем это без ее ведома. Откроем диск в HEX-редакторе на Windows, например. Про Windows я, конечно, погорячился, но основная мысль сохраняется:
- создадим «диск» в виде файла на 50 МБ,
- разметим файловую систему внутри файла,
- примонтируем содержимое файла в каталог mnt,
- создадим файл с названием 12345678,
- отмонтируем «диск»,
- через HEX-редактор изменим имя файла,
- примонтируем «диск» и проверим успешность затеи.
Благодаря идее «все есть файл» для операционной системы нет разницы между файлом-диском и обычным файлом. Это позволяет создать файловую систему не на разделе диска, а в обычном файле. А потом примонтировать этот файл как будто это диск.
Выполняем подготовку:
# Создаем файл
dd if=/dev/zero of=img bs=1M count=50
# Создаем файловую систему
mkfs.ext4 img
# Монтируем диск
mkdir mnt
mount img mnt
# Пустой файл
touch mnt/12345678
# Отмонтируем
umount mnt
# Переименовываем 12345678 в 87654321
sed -i 's/12345678/87654321/g' img
Для переименования я использовал неинтерактивный текстовый редактор sed, он отлично справляется со своей задачей. Монтируем:
void@ubuntu-2204:~# mount img mnt
void@ubuntu-2204:~# ls -l mnt
ls: reading directory 'mnt': Bad message
total 0
Ого, плохие ворота плохое сообщение. В циклическом логе ядра можно найти более подробное объяснение:
[36446.876771] EXT4-fs error (device loop1): htree_dirblock_to_tree:1080: inode #2: comm ls: Directory block failed checksum
Логично. Файловые системы работают с аппаратным обеспечением, которое в силу своей физической природы может дать сбой. Контрольные суммы позволяют обнаруживать и сообщать об ошибках. Воспользуемся утилитой e2fsck для проверки файловой системы.
void@ubuntu-2204:~# e2fsck img
e2fsck 1.46.5 (30-Dec-2021)
img contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 2, block #0: directory passes checks but fails checksum.
Fix<y>? yes
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
img: ***** FILE SYSTEM WAS MODIFIED *****
img: 13/12800 files (7.7% non-contiguous), 1840/12800 blocks
void@ubuntu-2204:~#
Монтируем и проверяем заново:
void@ubuntu-2204:~# ls -l mnt/
total 16
-rw-r--r-- 1 void root 0 Mar 5 18:44 87654321
-rw-r--r-- 1 void root 0 Mar 5 18:31 blablabla
drwx------ 2 void root 16384 Mar 5 18:26 lost+found
Сработало. Тогда попробуем первое испытание: создадим два файла и переименованием назначим им одно имя.
void@ubuntu-2204:~/mnt# ls -li
total 24
12 -rw-r--r-- 1 void root 2 Mar 5 19:26 1.txt
13 -rw-r--r-- 1 void root 20 Mar 5 19:26 2.txt
11 drwx------ 2 void root 16384 Mar 5 18:26 lost+found
void@ubuntu-2204:~/mnt# cat 1.txt
1
void@ubuntu-2204:~/mnt# cat 2.txt
2222222222222222222
void@ubuntu-2204:~/mnt#
Переименовываем и запускаем пересчет контрольной суммы:
void@ubuntu-2204:~# e2fsck img
e2fsck 1.46.5 (30-Dec-2021)
img contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Duplicate entry 'a.txt' found.
Marking ??? (2) to be rebuilt.
Directory inode 2, block #0: directory passes checks but fails checksum.
Fix<y>? yes
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Entry 'a.txt' in / (2) has a non-unique filename.
Rename to a.txt~0<y>? no
Pass 4: Checking reference counts
Pass 5: Checking group summary information
img: ***** FILE SYSTEM WAS MODIFIED *****
img: ********** WARNING: Filesystem still has errors **********
img: 13/12800 files (7.7% non-contiguous), 1842/12800 blocks
void@ubuntu-2204:~# mount img mnt/
Утилита e2fsck исправляет контрольную сумму и находит неуникальное имя. Мы, в свою очередь, отказываемся от переименования и монтируем «диск». Что мы видим?
void@ubuntu-2204:~# ls -li mnt
total 24
12 -rw-r--r-- 1 void root 2 Mar 5 19:26 a.txt
12 -rw-r--r-- 1 void root 2 Mar 5 19:26 a.txt
11 drwx------ 2 void root 16384 Mar 5 18:26 lost+found
void@ubuntu-2204:~# cat mnt/a.txt
1
Драйвер системы выдает небольшую аномалию: файл с меньшим числовым идентификатором, номером inode, отображается два раза. При этом все обращения из интерпретатора командной строки взаимодействуют именно с «первым» файлом.
void@ubuntu-2204:~# rm mnt/a.txt
void@ubuntu-2204:~# ls -l mnt/
ls: cannot access 'mnt/a.txt': No such file or directory
total 16
? -????????? ? ? ? ? ? a.txt
drwx------ 2 void root 16384 Mar 5 18:26 lost+found
void@ubuntu-2204:~# cat mnt/a.txt
cat: mnt/a.txt: No such file or directory
void@ubuntu-2204:~# umount mnt
void@ubuntu-2204:~# mount img mnt/
void@ubuntu-2204:~# ls -li mnt/
total 20
13 -rw-r--r-- 1 void root 20 Mar 5 19:26 a.txt
11 drwx------ 2 void root 16384 Mar 5 18:26 lost+found
void@ubuntu-2204:~# cat mnt/a.txt
2222222222222222222
Если удалить файл, то его «тезка» перейдет в состояние кота Шредингера. Файл есть, автодополнение по имени работает, но файла нет. После перемонтирования файловой системы второй файл без проблем находится.
Теперь сделаем страшное и добавим символ-разделитель:
void@ubuntu-2204:~# cat >mnt/split-me.txt
Hello, Habr!
void@ubuntu-2204:~# umount mnt
void@ubuntu-2204:~# sed -i 's/split-me.txt/split/me.txt/g' img
void@ubuntu-2204:~# e2fsck img
e2fsck 1.46.5 (30-Dec-2021)
img contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'split/me.txt' in ??? (2) has illegal characters in its name.
Fix<y>? no
Directory inode 2, block #0: directory passes checks but fails checksum.
Fix<y>? yes
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
img: ***** FILE SYSTEM WAS MODIFIED *****
img: ********** WARNING: Filesystem still has errors **********
img: 12/12800 files (8.3% non-contiguous), 1841/12800 blocks
Проверка находит такую ошибку, но не считает ее критичной. Хорошо, монтируем:
void@ubuntu-2204:~# ls -l mnt/
ls: reading directory 'mnt/': Input/output error
total 16
drwx------ 2 void root 16384 Mar 5 18:26 lost+found
void@ubuntu-2204:~# ls -l mnt/split/me.txt
ls: cannot access 'mnt/split/me.txt': No such file or directory
void@ubuntu-2204:~# mkdir mnt/split
void@ubuntu-2204:~# cat mnt/split/me.txt
cat: mnt/split/me.txt: No such file or directory
void@ubuntu-2204:~# echo Wow > mnt/split/me.txt
void@ubuntu-2204:~# cat mnt/split/me.txt
Wow
Результат не заставляет себя долго ждать.
- Частично сломалось отображение содержимого каталога. Объекты с номером inode больше, чем у «сломанного» файла, не попадут в вывод.
- Сам «сломанный» файл недоступен.
С одной стороны, это пример хорошей устойчивости к ошибкам. С другой — этой проблеме не день и не два, а 45 лет, если брать за точку отсчета выход UNIX v7.
Статья посвящена семейству операционных систем *NIX. Но в процессе написания стало интересно как такие ситуации обрабатывают «оконные» файловые системы.
Возможно, эти тексты тоже вас заинтересуют:
→ Figma закрыла Dev Mode: пути обхода и их краткий обзор
→ Мини-ПК для «тяжелых» и не очень задач: 5 моделей начала весны 2024 года
→ 10нм техпроцесс и 6 ГГц: Intel ставит новые рекорды производительности чипов. Что нового?
exFAT
Брать NTFS кажется избыточным. Но статья началась из-за бага на флешке фотоаппарата. Там используется файловая система от Microsoft — exFAT. Это преемник FAT, предназначенный для съемных носителей. Отличный кандидат. Хотя для Ubuntu 22.04 необходимо поставить именно exfat-fuse.
Теперь можно создать образ как раньше:
void@ubuntu-2204:~# dd if=/dev/zero of=img bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.024757 s, 2.1 GB/s
void@ubuntu-2204:~# mkfs.exfat img
exfatprogs version : 1.1.3
Creating exFAT filesystem(img, cluster size=4096)
Writing volume boot record: done
Writing backup volume boot record: done
Fat table creation: done
Allocation bitmap creation: done
Upcase table creation: done
Writing root directory entry: done
Synchronizing...
exFAT format complete!<br>void@ubuntu-2204:~# mount img mnt
void@ubuntu-2204:~# cat > mnt/1.txt
111111111111111111111111
void@ubuntu-2204:~# cat > mnt/2.txt
222222222222222222222
Заменить имя файла через sed уже не получится: для имен exFAT использует кодировку UTF-16. Хорошо, воспользуемся интерпретатором Python и напишем такой скрипт:
import sys
file, pattern, replace = sys.argv[1:4]
pattern = pattern.encode("utf-16le")
replace = replace.encode("utf-16le")
with open(file, "rb") as f:
raw_data = f.read()
raw_data = raw_data.replace(pattern, replace)
with open(file, "wb") as f:
f.write(raw_data)
Неэффективно по памяти, но для образа в 50 МБ это не проблема. Производим замену:
void@ubuntu-2204:~# python3 replace.py img 2.txt 1.txt
void@ubuntu-2204:~# mount img mnt
void@ubuntu-2204:~# ls -li mnt/
total 8
10 -rwxr-xr-x 1 void root 25 Mar 5 20:48 1.txt
10 -rwxr-xr-x 1 void root 25 Mar 5 20:48 1.txt
Реакция Ubuntu не поменялась: доступен только первый файл. Аналогично с UNIX-разделителем. А вот Windows-разделитель вносит смуту, но отображает файл:
void@ubuntu-2204:~# ls -l mnt/
ls: cannot access 'mnt/2txt': No such file or directory
total 4
-rwxr-xr-x 1 void root 25 Mar 5 20:48 1.txt
-????????? ? ? ? ? ? '2txt'
void@ubuntu-2204:~# ls -l mnt/2\txt
ls: cannot access 'mnt/2txt': No such file or directory
Проверим на Windows и записываем на флешку.
dd if=img of=/dev/<здесь мой диск> bs=4M
Уведомление в Windows 10.
Проигнорировать исправление ошибок нельзя.
Windows тут же определяет накопитель и предлагает исправить ошибки. Исправление ошибок — это предложение, от которого нельзя отказаться. Потому что иначе не получится просмотреть содержимое накопителя в графическом интерфейсе.
Консоль топ.
Командная строка покажет первые файлы, но потом запнется на «сломанном» файле. Прочитать, однако, файлы рядом возможно.
Абстракции для файловых систем в *NIX — это не только универсальный интерфейс, но и отличная устойчивость к ошибкам. Что думаете по поводу рассмотренных артефактов вы? Поделитесь своим мнением в комментариях!
Автор: Владимир
