Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Файловый дескриптор
Все открытые файлы ссылаются к ядру через так называемые файловые дескрипторы. Файловый дескриптор — это неотрицательное целое число. Когда мы открываем существующий файл и создаем новый файл, ядро возвращает процессу файловый дескриптор.
Содержание
По умолчанию UNIX-шеллы связывают файловый дескриптор 0 со стандартным вводом процесса (терминал), файловый дескриптор 1 — со стандартным выводом (терминал), и файловый дескриптор 2 — со стандартной ошибкой (то есть то куда выводятся сообщения об ошибках). Это соглашение соблюдается многими UNIX-шеллами и многими приложениями — и в ни коем случае не является составной частью ядра.
Стандарт POSIX.1 заменил «магические числа» 0,1,2 символическими константами STDIN_FILENO, STDOUT_FILENO и STDERR_FILENO соответственно.
Файловые дескрипторы могут принимать значения от 0 до OPEN_MAX. Старые версии UNIX имели верхний предел до 19, позволяя одному процессу открывать до 20 файлов. Сейчас это значение увеличено до нескольких тысяч.
Таблицы дескрипторов файлов и системные таблицы открытых файлов
Структуры данных, содержащие список открытых файлов и список дескрипторов файлов, позволяют отслеживать обращения процессов к файлам и гарантировать целостность данных.
Таблица дескрипторов файлов
Преобразует индексы таблицы (дескрипторы файлов) в указатели на открытые файлы. Для каждого процесса в области u_block создается своя собственная таблица дескрипторов. Каждая запись такой таблицы содержит следующие поля: поле флагов и указатель на файл. Допустимо не более OPEN_MAX дескрипторов файлов. Таблица дескрипторов файлов имеет следующую структуру:
Таблица открытых файлов
Управление дескрипторами файлов
Несколько обращений к файлу может потребоваться в следующих случаях:
Совместная работа с открытыми файлами
При выполнении каждой операции открытия в таблицу открытых файлов добавляется запись. Это гарантирует, что каждый процесс будет работать со своим указателем в файле. Такой подход позволяет сохранить целостность данных.
При копировании дескриптора два процесса начинают работать с одним и тем же указателем. В этом случае оба процесса могут попытаться одновременно обратиться к файлу, при этом данные будут считаны или записаны не последовательно.
Копирование дескрипторов файлов
Функции dup и dup2
Функция fork
Функция fcntl
Стандартные дескрипторы файлов
При запуске программы в оболочке открывается три дескриптора 0, 1 и 2. По умолчанию с ними связаны следующие файлы:
| 0 | Стандартный ввод. |
| 1 | Стандартный вывод. |
| 2 | Стандартный вывод сообщений об ошибках. |
Перечисленные дескрипторы файлов связаны с терминалом. Это означает, что при чтении данных из файла с дескриптором 0 программа получает ввод с терминала, а при записи данных в файлы с дескрипторами 1 и 2 они выводятся на терминал. При открытии других файлов дескрипторы присваиваются в порядке возрастания.
Если ввод-вывод перенаправляется с помощью операторов (знак больше), то стандартные дескрипторы связываются с другими файлами. Например, следующая команда связывает дескрипторы файлов 0 и 1 с необходимыми файлами (по умолчанию эти дескрипторы связаны с терминалом).
В следующем примере программы продемонстрировано перенаправление стандартного вывода:
При получении запроса на дескриптор выделяется первый свободный дескриптор из таблицы дескрипторов (дескриптор с наименьшим номером). Однако с помощью функции dup файлу можно присвоить любой дескриптор.
Ограничение на число дескрипторов файлов
Решение задания с pwnable.kr 01 — fd. Файловые дескрипторы и процессы
Специально для тех, кто хочет узнавать что-то новое и развиваться в любой из сфер информационной и компьютерной безопасности, я буду писать и рассказывать о следующих категориях:
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.
Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.
Файловые дескрипторы
Файловый дескриптор — это неотрицательное число, которое является идентификатором какого-либо потока ввода-вывода, который может быть связан с файлами, каталогами или сокетами.
В системной файловой таблице (SFT — System File Table) и таблице индексных дескрипторов (INode Table) содержится информация, необходимая для доступа процесса к данным файла. Если несколько процессов запрашивают доступ к одному и тому же файлу, то каждый из тих процессов получит собственный элемент системной файловой таблицы, несмотря на то что они будут работать с одним и тем же файлом.
Ядро предоставляет процессу файловый дескриптор, когда тот получает доступ к файлу. Можно сказать, что файловый дескриптор — это индекс массива открытых файлов, который является уникальным для каждого процесса. Но первые три индекса жестко закреплены:
Решение задания fd
Нажимаем на первую иконку с подписью fd, и нам говорят, что нужно подключиться по SSH с паролем guest.
При подключении мы видим соотвтствующий баннер.
Давайте узнаем какие файлы есть на сервере, а также какие мы имеем права.
Таким образом мы можем можем прочитать исходный код программы, так как есть право читать для всех, и выполнить с правами владельца программу fd (установлен sticky-бит). Давай просмотрим исходный код.
Из кода следует, что программа принимает в качестве параметра число, отнимает от него 0x1234 и использует в качестве дескриптора для получения строки, которая должна быть равна «LETMEWIN».
Таким образом нам нужно послать программе строку «LETMEWIN» через стандартный поток ввода (stdin). Для этого дескриптор, который передается в функцию read(), должен быть равен 0. То есть в качестве параметра программы нужно использовать число 0х1234. Переведем его в десятичный вид.
Теперь запустим программу с параметром 4660, отпавим нужную строку и заберем флаг.
Что такое файловый описатель
С точки зрения модели КИС (Клиент-Интерфейс-Сервер), сервером стандартных механизмов ввода вывода языка C (printf, scanf, FILE*, fprintf, fputc и т. д.) является библиотека языка. А сервером низкоуровневого ввода-вывода в Linux, которому посвящена эта глава книги, является само ядро операционной системы.
Пользовательские программы взаимодействуют с ядром операционной системы посредством специальных механизмов, называемых системными вызовами (system calls, syscalls). Внешне системные вызовы реализованы в виде обычных функций языка C, однако каждый раз вызывая такую функцию, мы обращаемся непосредственно к ядру операционной системы. Список всех системных вызовов Linux можно найти в файле /usr/include/asm/unistd.h. В этой главе мы рассмотрим основные системные вызовы, осуществляющие ввод-вывод: open(), close(), read(), write(), lseek() и некоторые другие.
5.2. Файловые дескрипторы
Вы уже знаете из предыдущей главы, что при запуске программы в системе создается новый процесс (здесь есть свои особенности, о которых пока говорить не будем). У каждого процесса (кроме init) есть свой родительский процесс (parent process или просто parent), для которого новоиспеченный процесс является дочерним (child process, child). Каждый процесс получает копию окружения (environment) родительского процесса. Оказывается, кроме окружения дочерний процесс получает в качестве багажа еще и копию таблицы файловых дескрипторов.
Возникает вопрос: сколько файлов может открыть процесс? В каждой системе есть свой лимит, зависящий от конфигурации. Если вы используете bash или ksh (Korn Shell), то можете воспользоваться внутренней командой оболочки ulimit, чтобы узнать это значение. Если вы работаете с оболочкой C-shell (csh, tcsh), то в вашем распоряжении команда limit:
В командной оболочке, в которой вы работаете (bash, например), открыты три файла: стандартный ввод (дескриптор 0), стандартный вывод (дескриптор 1) и стандартный поток ошибок (дескриптор 2). Когда под оболочкой запускается программа, в системе создается новый процесс, который является для этой оболочки дочерним процессом, следовательно, получает копию таблицы дескрипторов своего родителя (то есть все открытые файлы родительского процесса). Таким образом программа может осуществлять консольный ввод-вывод через эти дескрипторы. На протяжении всей книги мы будем часто играть с этими дескрипторами.
Таблица дескрипторов, помимо всего прочего, содержит информацию о текущей позиции чтения-записи для каждого дескриптора. При открытии файла, позиция чтения-записи устанавливается в ноль. Каждый прочитанный или записанный байт увеличивает на единицу указатель текущей позиции. Мы вернемся к этой теме в разделе 5.7.
5.3. Открытие файла: системный вызов open()
Чтобы получить возможность прочитать что-то из файла или записать что-то в файл, его нужно открыть. Это делает системный вызов open(). Этот системный вызов не имеет постоянного списка аргументов (за счет использования механизма va_arg); в связи с этим существуют две «разновидности» open(). Не только в С++ есть перегрузка функций 😉 Если интересно, то о механизме va_arg можно прочитать на man-странице stdarg (man 3 stdarg) или в книге Б. Кернигана и Д. Ритчи «Язык программирования Си». Ниже приведены адаптированные прототипы системного вызова open().
Системный вызов open() объявлен в заголовочном файле fcntl.h. Ниже приведен общий адаптированный прототип open().
5.4. Закрытие файла: системный вызов close()
Системный вызов close() закрывает файл. Вообще говоря, по завершении процесса все открытые файлы (кроме файлов с дескрипторами 0, 1 и 2) автоматически закрываются. Тем не менее, это не освобождает нас от самостоятельного вызова close(), когда файл нужно закрыть. К тому же, если файлы не закрывать самостоятельно, то соответствующие дескрипторы не освобождаются, что может привести к превышению лимита открытых файлов. Простой пример: приложение может быть настроено так, чтобы каждую минуту открывать и перечитывать свой файл конфигурации для проверки обновлений. Если каждый раз файл не будет закрываться, то в моей системе, например, приложение может «накрыться медным тазом» примерно через 17 часов. Автоматически! Кроме того, файловая система Linux поддерживает механизм буферизации. Это означает, что данные, которые якобы записываются, реально записываются на носитель (синхронизируются) только через какое-то время, когда система сочтет это правильным и оптимальным. Это повышает производительность системы и даже продлевает ресурс жестких дисков. Системный вызов close() не форсирует запись данных на диск, однако дает больше гарантий того, что данные останутся в целости и сохранности.
Системный вызов close() объявлен в файле unistd.h. Ниже приведен его адаптированный прототип.
Теперь можно написать простенкую программу, использующую системные вызовы open() и close(). Мы еще не умеем читать из файлов и писать в файлы, поэтому напишем программу, которая создает файл с именем, переданным в качестве аргумента (argv[1]) и с правами доступа 0600 (чтение и запись для пользователя). Ниже приведен исходный код программы.
Обратите внимание, если запустить программу дважды с одним и тем же аргументом, то на второй раз open() выдаст ошибку. В этом виноват флаг O_EXCL (см. Таблицу 4 Приложения 2), который «дает добро» только на создание еще не существующих файлов. Наглядности ради, флаги открытия и флаги режима мы занесли в отдельные переменные, однако можно было бы сделать так: Или так:
5.5. Чтение файла: системный вызов read()
Системный вызов read(), объявленный в файле unistd.h, позволяет читать данные из файла. В отличие от библиотечных функций файлового ввода-вывода, которые предоставляют возможность интерпретации считываемых данных. Можно, например, записать в файл следующее содержимое:
Теперь, используя библиотечные механизмы, можно читать файл по-разному:
Системный вызов read() читает данные в «сыром» виде, то есть как последовательность байт, без какой-либо интерпретации. Ниже представлен адаптированный прототип read().
Теперь напишем программу, которая просто читает файл и выводит его содержимое на экран. Имя файла будет передаваться в качестве аргумента (argv[1]). Ниже приведен исходный код этой программы.
Как можно заметить, в нашем примере системный вызов read() вызывается ровно столько раз, сколько байт содержится в файле. Иногда это действительно нужно; но не здесь. Чтение-запись посимвольным методом (как в нашем примере) значительно замедляет процесс ввода-вывода за счет многократных обращений к системным вызовам. По этой же причине возрастает вероятность возникновения ошибки. Если нет действительной необходимости, файлы нужно читать блоками. О том, какой размер блока предпочтительнее, будет рассказано в последующих главах книги. Ниже приведен исходный код программы, которая делает то же самое, что и предыдущий пример, но с использованием блочного чтения файла. Размер блока установлен в 64 байта.
Теперь можно примерно оценить и сравнить скорость работы двух примеров. Для этого надо выбрать в системе достаточно большой файл (бинарник ядра или видеофильм, например) и посмотреть на то, как быстро читаются эти файлы:
5.6. Запись в файл: системный вызов write()
Для записи данных в файл используется системный вызов write(). Ниже представлен его прототип.
В этом примере нам уже не надо изощеряться в попытках вставить нуль-терминатор в строку для записи, поскольку системный вызов write() не запишет большее количество байт, чем мы ему указали. В данном случае для демонстрации write() мы просто записывали данные в файл с дескриптором 1, то есть в стандартный вывод. Но прежде, чем переходить к чтению следующего раздела, попробуйте самостоятельно записать что-нибудь (при помощи write(), естественно) в обычный файл. Когда будете открывать файл для записи, обратите пожалуйста внимание на флаги O_TRUNC, O_CREAT и O_APPEND. Подумайте, все ли флаги сочетаются между собой по смыслу.
5.7. Произвольный доступ: системный вызов lseek()
Как уже говорилось, с каждым открытым файлом связано число, указывающее на текущую позицию чтения-записи. При открытии файла позиция равна нулю. Каждый вызов read() или write() увеличивает текущую позицию на значение, равное числу прочитанных или записанных байт. Благодаря этому механизму, каждый повторный вызов read() читает следующие данные, и каждый повторный write() записывает данные в продолжение предыдущих, а не затирает старые. Такой механизм последовательного доступа очень удобен, однако иногда требуется получить произвольный доступ к содержимому файла, чтобы, например, прочитать или записать файл заново.
Для изменения текущей позиции чтения-записи используется системный вызов lseek(). Ниже представлен его прототип.
Первый вызов устанавливает текущую позицию в начало файла. Второй вызов смещает позицию вперед на 20 байт. В третьем случае текущая позиция перемещается на 10 байт назад относительно конца файла.
Я долго думал, какой бы пример придумать, чтобы продемонстрировать работу lseek() наглядным образом. Наиболее подходящим примером мне показалась идея создания программы рисования символами. Программа оказалась не слишком простой, однако если вы сможете разобраться в ней, то можете считать, что успешно овладели азами низкоуровневого ввода-вывода Linux. Ниже представлен исходный код этой программы.
Функция init_draw() пишет в файл N_ROWS строк, каждая из которых содержит N_COLS пробелов, заканчивающихся переводом строки. Это процедура подготовки «холста».
Функция draw_point() вычисляет позицию (исходя из значений координат), перемещает туда текущую позицию ввода-вывода файла, и записывает в эту позицию символ (FG_CHAR), которым мы рисуем «картину».
Функция draw_hline() заполняет часть строки символами FG_CHAR. Так получается горизонтальная линия. Функция draw_vline() работает иначе. Чтобы записать вертикальную линию, нужно записывать по одному символу и каждый раз «перескакивать» на следующую строку. Эта функция работает медленнее, чем draw_hline(), но иначе мы не можем.
Полученное изображение записывается в файл image. Будьте внимательны: чтобы разгрузить исходный код, из программы исключены многие проверки (read(), write(), close(), диапазон координат и проч.). Попробуйте включить эти проверки самостоятельно.
Что такое файловые дескрипторы, объясненные в простых терминах?
что было бы более упрощенным описанием файловых дескрипторов по сравнению с Wikipedia? Зачем они нужны? Скажем, возьмем в качестве примера процессы shell и как они применяются для этого?
содержит ли таблица процессов более одного файлового дескриптора. Если да, то почему?
10 ответов
простыми словами, когда вы открываете файл, операционная система создает запись для представления этого файла и хранения информации об этом открытом файле. Поэтому, если в вашей ОС открыто 100 файлов, то в ОС будет 100 записей (где-то в ядре). Эти записи представлены целыми числами, такими как (. 100, 101, 102. ). Этот номер записи является дескриптором файла. Таким образом, это просто целое число, которое однозначно представляет открытый файл в операционной системе. Если процесс открывает 10 файлы тогда ваша таблица процессов будет иметь 10 записей для файловых дескрипторов.
аналогично, когда вы открываете сетевой сокет, он также представлен целым числом и называется дескриптором сокета. Надеюсь, вы понимаете.
услышать это из уст лошади: APUE (Ричард Стивенс).
На ядро все открытые файлы ссылаются файловыми дескрипторами. Файловый дескриптор-неотрицательное число.
когда мы открываем существующий файл или создать новый файл, ядро возвращает файловый дескриптор процесса. ядро поддерживает таблицу всех открытых файловых дескрипторов, которые используются. Выделение файловых дескрипторов обычно является последовательным, и они выделяются в файл в качестве следующего свободного файлового дескриптора из пула свободных файловых дескрипторов. Когда мы закрываем файл, дескриптор файла освобождается и доступен для дальнейшего выделения.
См. это изображение для получения более подробной информации:
когда мы хотим прочитать или записать файл, то найдите файл с дескриптором файла, который был возвращен открыть() или create () вызов функции и используйте его в качестве аргумента либо read () или write ().
По соглашению, системные оболочки UNIX связывают файловый дескриптор 0 с Стандартный Ввод процесса, файловый дескриптор 1 с Стандартный Вывод, и файл desciptor 2 с Стандартная Ошибка.
Файловый дескриптор колеблется от 0 до OPEN_MAX.
Для получения дополнительной информации пройдите 3-ю главу книги APUE.
в дополнение к другим ответам unix рассматривает все как файловую систему. Клавиатуре-это файл, который читается только с точки зрения ядра. Экран-это файл только для записи. Аналогично, папки, устройства ввода-вывода и т. д. также считаются файлами. Всякий раз, когда файл открыт, скажем, когда драйверы устройств[для файлов устройств] запрашивают open () или процесс открывает файл пользователя, ядро выделяет файловый дескриптор, целое число, указывающее доступ к этому файлу, например быть прочитанным только, напишите только etc. [для справки : https://en.wikipedia.org/wiki/Everything_is_a_file ]
больше очков в отношении File Descriptor :
FD распределяются в последовательном порядке, что означает наименьшее возможное нераспределенное целое значение.
FD для определенного процесса можно увидеть в /proc/$pid/fd (в системах на базе Unix).
любая операционная система имеет запущенные процессы (p), скажем p1, p2, p3 и так далее. Каждый процесс обычно делает постоянное использование файлов.
каждый процесс состоит из дерева процессов (или таблицы процессов, в другой формулировке).
обычно операционные системы представляют каждый файл в каждом процессе by a (то есть в каждом дереве/таблице процессов).
любое такое число является дескриптором файла.
файловые дескрипторы обычно являются целыми числами (0, 1, 2, а не 0.5, 1.5, 2.5).
учитывая, что мы часто описываем процессы как «process-tables», и учитывая, что таблицы имеют строки (записи), мы можем сказать, что ячейка файлового дескриптора в каждой записи использует для представления всей записи.
в аналогичной кстати, когда вы открываете сетевой сокет, он имеет дескриптор сокета.
в некоторых операционных системах у вас могут закончиться файловые дескрипторы, но такой случай крайне редок, и средний пользователь компьютера не должен беспокоиться об этом.
файловые дескрипторы могут быть глобальными (процесс A начинается в 0, а заканчивается в 1 ; Процесс B начинается в 2, а заканчивается в 3) и т. д., Но, насколько я знаю, обычно в современных операционных системах файловые дескрипторы не являются глобальными и являются на самом деле процесс специфичен (процесс A начинается в 0 и заканчивается в 5, в то время как процесс B начинается в 0 и заканчивается в 10).
другие ответы добавили отличный материал. Я добавлю только мои 2 цента.
согласно Википедии, мы точно знаем: дескриптор файла является неотрицательным целым числом. Самое главное, что я думаю, отсутствует, было бы сказать:
файловые дескрипторы привязаны к ID процесса.
скажем, взять shell обрабатывает в качестве примера и как он применяется для него?
проверьте этот код
4-й столбец FD и самый Следующий тип столбца соответствуют файловому дескриптору и типу файлового дескриптора.
некоторые из значений для FD могут быть:
но реальный файловый дескриптор в разделе:
символ после числа i.e «1u», представляет режим, в котором файл открывается. r для чтения, w для записи, u для чтения и записи.
TYPE указывает тип файла. Некоторые из значений типов:
но все файловые дескрипторы Chr-символьный специальный файл (или файл символьного устройства)
Обратите также внимание, что таблица дескрипторов файлов, которую отслеживает ядро, не совпадает с таблицей файлов или таблицей индексов. Они разделены, как объяснялось в некоторых других ответах.
вы можете спросить себя, где эти файловые дескрипторы физически и то, что хранится в /dev/pts/6 например
просто вспомнить большинство Linux, как OS определить семь типов файлов:
файловые дескрипторы (FD) :
дескриптор файла для стандартной ошибки 2.
Если нет никакого каталога с именем mydir, то вывод команды будет сохранен в файл errorfile.txt
Используя «2>», мы перенаправляем вывод ошибки в файл с именем » errorfile.txt»
Таким образом, вывод программы не загроможден ошибками.
надеюсь, вы получили ответ.
файловые дескрипторы
файловые дескрипторы-это дескрипторы файла. Они дают ссылки на файл. С их помощью мы можем читать, писать и открывать файлы.
Что такое файловый дескриптор простыми словами
Файловый дескриптор — это неотрицательное число, которое является идентификатором потока ввода-вывода. Дескриптор может быть связан с файлом, каталогом, сокетом.
Например, когда вы открываете или создаете новый файл, операционная система формирует для себя запись для представления этого файла и хранения информации о нем. У каждого файла индивидуальный файловый дескриптор Linux. Открыли 100 файлов — где-то в ядре появились 100 записей, представленных целыми числами.
Как файлы получают дескрипторы
Обычно файловые дескрипторы выделяются последовательно. Есть пул свободных номеров. Когда вы создаете новый файл или открываете существующий, ему присваивается номер. Следующий файл получает очередной номер — например, 101, 102, 103 и так далее.
Дескриптор для каждого процесса является уникальным. Но есть три жестко закрепленных индекса — это первые три номера (0, 1, 2).
Когда вы завершаете работу с файлом, присвоенный ему дескриптор освобождается и возвращается в пул свободных номеров. Он снова доступен для выделения под новый файл. 
В Unix-подобных системах файловые дескрипторы могут относиться к любому типу файлов Unix: обычным файлам, каталогам, блочным и символьным устройствам, сокетам домена, именованным каналам. Дескрипторы также могут относиться к объектам, которые не существуют в файловой системе: анонимным каналам и сетевым сокетам.
Понятием «файловый дескриптор» оперируют и в языках программирования. Например, в Python функция os.open(path, flags, mode=0o777, *, dir_fd=None) открывает путь к файлу path, добавляет флаги и режим, а также возвращает дескриптор для вновь открытого файла. Начиная с версии 3.4 файловые дескрипторы в дочернем процессе Python не наследуются. В Unix они закрываются в дочерних процессах при выполнении новой программы.
Для чего нужны файловые дескрипторы
Чтобы оценить важность файловых дескрипторов, нужно разобраться, как работает файловая система.
Когда нужно выполнить ввод или вывод, процесс через системный вызов передает ядру дескриптор нужного файла. Ядро обращается к файлу от имени процесса. При этом у самого процесса нет доступа к файлу или таблице индексных дескрипторов.
Что такое плохой файловый дескриптор
Это ошибка, которая может возникнуть в многопоточных приложениях, — Bad file descriptor. Чтобы исправить ее, нужно найти код, который закрывает один и тот же дескриптор файла. Может произойти и другая ситуация — например, один поток уже закрыл файл, а другой поток пытается получить к нему доступ.
В однопоточных приложениях такая проблема обычно не возникает.
Что можно делать с файловыми дескрипторами
Файловые дескрипторы можно использовать для исправления ошибок. Например, если на диске нет свободного места, но вы не видите файлы, которые занимают пространство, то можно посмотреть открытые дескрипторы. Это поможет понять, какое приложение заняло весь доступный объем.
Важно понимать, что если мы один раз открыли файл, и он получил файловый дескриптор, то мы можем взаимодействовать с ним дальше. Не имеет значения, что с этим файлом происходит. Его могут переименовать, удалить, могут изменить его владельца, отобрать права на запись и чтение. Если вы уже начали работать с файлом и знаете его дескриптор, то можете продолжать с ним работать.