Восстановить удалённый файл через /proc

Демон secret-writer открыл /data/secret.txt на запись и продолжает
дописывать туда данные (лог-стиль). Кто-то случайно сделал rm /data/secret.txt.
Самого файла на диске уже нет, но процесс всё ещё держит его открытым через
файловый дескриптор — а значит, содержимое всё ещё доступно через /proc.

Задача

Восстановите текущее содержимое в файл /tmp/recovered-secret.txt. Конкретно:
там должна оказаться строка, начинающаяся с the-password-is- (маркер лабы),
за которой идёт сам пароль.

Симптомы

$ ls /data/secret.txt
ls: cannot access '/data/secret.txt': No such file or directory

$ ls -l /proc/$(pgrep -f secret-writer)/fd/ 2>/dev/null | head
total 0
lrwx------ 1 root root 64 ... 0 -> /dev/null
lrwx------ 1 root root 64 ... 1 -> /dev/null
lrwx------ 1 root root 64 ... 2 -> /dev/null
l-wx------ 1 root root 64 ... 3 -> /data/secret.txt (deleted)  ← вот оно

Видите (deleted) у FD — это и есть «удалённый, но открытый» файл.

Как восстановить

Файл доступен как /proc/<pid>/fd/<n> — это символическая ссылка на inode
(пусть и помечена deleted). Можно её просто скопировать:

$ cp /proc/<pid>/fd/3 /tmp/recovered-secret.txt
$ cat /tmp/recovered-secret.txt
the-password-is-s3cret

<pid> = PID процесса secret-writer, <n> = номер FD со ссылкой на
удалённый файл.

Почему это hard

Это классический трюк с LKSF/forensics: «думали, файл пропал, а процесс его
держит». Реальные сценарии — случайно удалённые логи nginx/mysql, которые
продолжают занимать место на диске (FD жив → inode не освобождён), или
вытащить ключ из памяти работающего сервиса. Лабра учит читать /proc/<pid>/fd
и понимать разницу между именем файла и inode.

Подсказки

• pgrep -f secret-writer — найти PID процесса-владельца FD.
• ls -l /proc/<pid>/fd/ — увидеть все дескрипторы; найти строку с (deleted).
• cat /proc/<pid>/fd/<n> — прочитать содержимое, хотя имя файла удалено.
• cp /proc/<pid>/fd/<n> /tmp/recovered-secret.txt — восстановить.