Интересно, как это работает.

[beldmit]

Из Changelog новой версии ядра Linux (3.11, "Linux for workgroups"):

В системные вызовы open() и openat() добавлена поддержка флага O_TMPFILE, позволяющего передать файловой системе информацию о создании временного файла, не видимого в иерархии ФС, что позволяет применить для данного типа файлов отдельные оптимизации. Создаваемые при помощи O_TMPFILE временные файлы не имеют имени, в качестве пути передаётся только директория. Создание невидимого временного файла без имени позволяет разработчикам приложений не задумываться о возможных уязвимостях, таких, как атака через символические ссылки;

В ряде мест такая возможность сильно упростит жизнь. Но до широкого распространения, боюсь, еще долго.

Comments

[tobotras]

Дык, всю жизнь в юниксах было идиомой создать файл, открыть и сразу удалить. Дальше ты с ним работаешь, и файл жив только пока жив процесс, держащий файл-дескриптор. А тут просто не надо звать unlink(2), оптимизация.

[beldmit.livejournal.com]

Но в твоем варианте возможны гонки между созданием и удалением. Или нет?

[tobotras]

А в чём гонка-то? Не торопясь создал, потом не торопясь удалил, потом не торопясь работаешь с ним себе. Если тебя в неудачный момент застрелили -- ну, останется валяться нулевой длины /tmp/tmpsomething...

[qkowlew.livejournal.com]

как будто не бывает no free inodes :-)

[potan.livejournal.com]

В современных fs не бывает.

[beldmit.livejournal.com]

Два процесса создали файл с одинаковым именем.

[tobotras]

/tmp/tmpfile.MyApplication.$$ ? :)

[beldmit.livejournal.com]

Не, это само собой решение. Пока у тебя не мультитред.

[tobotras]

s/PID/TID/ :-)

[qkowlew.livejournal.com]

да. Атака по ошибке в коде на этом этапе рано или поздно ведет к no free inodes

[kouzdra.livejournal.com]

О! RSX-11M повеяло (там каталожная система была вообще отделена от файловой).

Или RT-11, где создаваемый файл включался в FS при выполнении операции enter (обычно при закрытии) - ну а если ее не было - то и не включался

[pukkallo.livejournal.com]

Ну, и здесь идет именно о временных, которые никогда не станут постоянным. Что, кроме security, имеет и бонус в виде не засранного при обломавшихся форках и иных зомби /tmp. Впрочем, вопрос с чисткой мусора при таком подходе таки встает ненавязчиво.

И причина возникновения сильно разная. В RT-11 это было вызвано не security reasons, а тем, что файл писался целым куском (RT, итить), и до момента финализации его размер не был точно известен. С этим проблема с многозадачными мониторами была - если места мало и squeeze не делали, могло не хватить места при записи. Регулярно сталкивался на СМ-4 с TS-монитором с этим.

[kouzdra.livejournal.com]

Вызвано было и в RSX и RT тем, что собственно совершенно непонятно, зачем вставлять файл в каталог при создании - и поэффективнее и проблем с изобретением уникальных имен нет (в RSX еще и тем, что идея разделить собственно файловую систему и каталожную довольно естественна - каталожная система сопоставляет тебе имени файла его ID, а собственно файловая работает только с плоским пространством ID)

PS: Проблемы с местом в RT к Enter отношения не имели - файл-то все равно писался на диск по ходу. Финализировалась именно запись в каталоге. Что кроме прочего позволяло безопасно овервратить файл новым с тем же именем (и вообще обеспечивало более естественную логику - без всех этих *~) - старый продолжал существовать до выполнения команды enter, а она емнимп была атомарная.

[pukkallo.livejournal.com]

По RSX-11 не скажу - прошла мимо. Однако, ЕМНИП, запись в каталоге в RT-11 имела в качестве своей составляющей ссылку на начало физического положения, а файл открывался в самом большом из доступных пустых мест (которые тоже писались в каталог наравне с файлами). Поэтому её финализация по close была естественной для модификации смежной пустой записи. Кроме того, в RT была какая-то команда (не помню точно) - некоторый аналог sync в UNIX, которая обновляла именно запись в каталоге на данный момент и позволяла не потерять сделанных изменений. Или мы это reopen делали ... давно было. Кстати, достоинство существования старого файла при любых сбоях была весьма приятственной особенностью. После смены религи мне этого регулярно не хватало.

Впрочем, я как-то больше пошел по прикладным, поэтому многих подробностей не помню. Надо поспрошать брата, который во времена оные написал на ассемблере аналог squeeze, который использовался на ... Откат был невозможен, при сбое умирало все, но работало раз в 5 быстрее :)

[kouzdra.livejournal.com]

Поэтому её финализация по close была естественной для модификации смежной пустой записи.

Разумеется - так для close подобные функции естественны довольно таки



А в RSX каталог был просто файлом с записями по 16B емнимп, которые устанвливали соответствие имяфайла -> его ID - (ID - пара - порядковый номер, контрольное значение, потом появился третий - номер устройства кажется, или хоста).

Файловый процессор в принципе умел по отдельному каталогу искать (хотя я так и не очень понял зачем), а уже работа с вложенными каталогами делалась просто на уровне user space библиотеки (что забавно - хотя структура была формально двух уровневой - главный каталог - пользовательские - зашито было исключительно на уровне соглашений об именовании файлов и соответствующих функций. Уже утилита Verify (тамошний fsck) работала с произвольной вложенностью каталогов и произвольными же их именами.

А собственно файл с точки зрения системы представлялся именно ID.

[gineer.livejournal.com]

\\Впрочем, вопрос с чисткой мусора при таком подходе таки встает ненавязчиво.

ужо
http://beldmit.livejournal.com/402695.html?thread=4380167#t4380167

последний Дебиан, если че. :)

[kouzdra.livejournal.com]

fsck все равно гоняется регулярно.

[gineer.livejournal.com]

вы из какого столетия?
счас все фсы с журналами ;)

[kouzdra.livejournal.com]

Я знаю - тем не менее -"гоняется регулярно"

[gineer.livejournal.com]

\\Впрочем, вопрос с чисткой мусора при таком подходе таки встает ненавязчиво.

ужо
http://beldmit.livejournal.com/402695.html?thread=4380167#t4380167

последний Дебиан, если че. :)

[oboguev.livejournal.com]

Скорее это child of mmap(MAP_ANON), ну или для тех, кто помнит, что было раньше, SYS$CRMPSC(SEC$M_PAGFIL).

[kouzdra.livejournal.com]

Там скорее поиски решения проблемы, которой в упомянутых системах не было by design - причем не по ошибке не было.

Ну да - само найденное решение - кривое. Но его источник - дурацкая идея привязать ресурс (файл) к записи в каталоге - в RSX оно кстати было отзеркалено на уровне процессов - там запуск задачи требовал ее обязательной регистрации - в результате была и команда RUN и всякие спецфункции которые автоматом выдумывали для процесса имя, его регистрировали, запускали, а по завершении - удаляли.

[http://users.livejournal.com/_iga/]

Это называется - встроили руткит прямо в ядро :-(

[gineer.livejournal.com]

о, по ходу я именно с этой фигней и столкнулся...
в виде, что-то отъедает раздел /тмп а самих файлов и не видать

[lodin]

Так это и в режиме "создал-удалил" можно отъесть, или нет?

[rdia.livejournal.com]

Да.

[gineer.livejournal.com]

ага
но там его хоть видно будет
и можно попробовать удалить и/или щелкнуть поносу процесс