Определение начальных прав доступа к файлу

 

Как пользователь GNU/Linux, вы знакомы с правами доступа к файлу, выдаваемыми командой '': на чтение, запись и исполнение для каждого из владельца файла, группы и остальных. Различные сочетания часто выражаются в восьмеричной форме, в частности, для команд и. Например, права доступа к файлу r‑‑ эквивалентны восьмеричному 0644, a эквивалентно восьмеричному 0755. (Ведущий 0 в нотации С означает восьмеричные значения.)

Когда вы создаете файл, вы должны знать, какую защиту необходимо назначить новому файлу. Вы можете сделать это с помощью простого восьмеричного числа, если захотите, и такие числа довольно обычно можно увидеть в старом коде. Однако, лучше использовать побитовую операцию OR для одной или более символических имен из, описанных в табл. 4.5.

 

Таблица 4.5. Символические имена POSIX для режимов доступа к файлу

 

Символическое имя	Значение	Комментарий
	00700	Разрешение на чтение, запись и исполнение для владельца
	00400	Разрешение на чтение для владельца
		Аналогично
	00200	Разрешение на запись для владельца
		Аналогично
	00100	Разрешение на исполнение для владельца.
		Аналогично
	00070	Разрешение на чтение, запись и исполнение для группы
	00040	Разрешение на чтение для группы
	00020	Разрешение на запись для группы.
	00010	Разрешение на исполнение для группы
	00007	Разрешение на чтение, запись и исполнение для остальных.
	00004	Разрешение на чтение для остальных.
	00002	Разрешение на запись для остальных
	00001	Разрешение на исполнение для остальных

Следующий фрагмент показывает, как создать переменные, представляющие разрешения и (0644 и 0755 соответственно):

 

Более старый код использовал, и вместе со сдвигом битов для получения того же результата:

 

 

К сожалению, ни одна из записей не является очень удобной. Современные версии предпочтительнее, поскольку у каждого бита доступа есть собственное имя и меньше вероятность неправильного выполнения побитовых операций.

При изменении прав доступа к файлу для использования доступны биты дополнительных разрешений, показанные в табл. 4.6, но они не должны использоваться при первоначальном создании файла. Возможность включения этих битов широко варьирует между операционными системами. Лучше всего не пробовать; вместо этого следует изменить права доступа к файлу явным образом после его создания. (Изменение прав доступа описано в разделе 5.5.2 «Изменение прав доступа: и». Значения этих битов обсуждаются в главе 11 «Права доступа и идентификаторы пользователя и группы».)

 

Таблица 4.6. Дополнительные символические имена POSIX для режимов доступа к файлам

 

Символическое имя	Значение	Смысл
	04000	Установить ID пользователя
	02000	Установить ID группы
	01000	Сохранить текст

Когда стандартные утилиты создают файлы, они по умолчанию используют права доступа (или 0666). Поскольку большинство пользователей предпочитают избегать файлов, в которые может записывать кто угодно, каждый процесс имеет при себе umask. является набором битов допуска, указывающим те биты, которые никогда не должны устанавливаться при создании новых файлов, (umask не используется при изменении прав доступа.) Концептуально осуществляется операция

 

 обычно устанавливается с помощью команды в, когда вы входите в систему. Из программы С она устанавливается с помощью системного вызова.

 

 

Возвращается старое значение. Поэтому для определения текущей маски нужно установить новое значение, а затем восстановить старое (или изменить его при необходимости):

 

 

Вот пример работы на уровне оболочки:

Umask

 

Touch newfile

ls ‑l newfile

 

Umask 0

Touch newfile2

ls ‑l newfile2

 

 

Создание файлов с помощью

 

Системный вызов [49] создает новые файлы. Он объявлен следующим образом:

 

Аргумент представляет права доступа к новому файлу (как обсуждалось в предыдущем разделе). Создается файл с именем данными правами доступа, модифицированными с использованием. Он открыт (только) для чтения, а возвращаемое значение является дескриптором нового файла или ‑1, если была проблема. В последнем случае указывает ошибку. Если файл уже существует, он будет при открытии урезан.

Во всех остальных отношениях дескрипторы файлов, возвращаемые, являются теми же самыми, которые возвращаются; они используются для записи и позиционирования и должны закрываться при помощи:

 

 

Возвращаясь к open()

 

Вы можете вспомнить объявление для:

 

Ранее мы сказали, что при открытии файла для простого ввода/вывода мы можем игнорировать аргумент. Хотя, посмотрев на, вы, возможно, догадались, что также может использоваться для создания файлов и что в этом случае используется аргумент. Это в самом деле так.

Помимо флагов, и, при вызове могут добавляться с использованием поразрядного дополнительные флаги. Стандарт POSIX предоставляет ряд этих дополнительных флагов. В табл. 4.7 представлены флаги, которые используются для большинства обычных приложений.

 

Таблица 4.7. Дополнительные флаги POSIX для

 

Флаг	Значение
	Принудительно осуществляет все записи в конец файла
	Создает новый файл, если он не существует.
	При использовании вместе с возвращает ошибку, если файл уже существует
	Урезает файл (устанавливает его длину в 0), если он существует.

Если даны и, можно представить, как оболочка могла бы открывать или создавать файлы, соответствующие операторам и. Например:

 

Обратите внимание, что флаг здесь не используется, поскольку как для, так и для не является ошибкой существование файла. Запомните также, что система применяет к запрошенным правам доступа.

Также легко видеть, что, по крайней мере концептуально, можно было бы легко написать следующим образом:

 

 

ЗАМЕЧАНИЕ. Если файл открыт с флагом, все данные будут записаны в конец файла, даже если текущее смещение было восстановлено с помощью.

 

Современные системы предоставляют дополнительные флаги с более специализированным назначением. Они кратко описаны в табл. 4.8.

 

Таблица 4.8. Дополнительные расширенные флаги POSIX для

 

Флаг	Значение
	Принудительно осуществляет все записи в конец файла
	Создает новый файл, если он не существует.
	При использовании вместе с возвращает ошибку, если файл уже существует
	Урезает файл (устанавливает его длину в 0), если он существует.

Флаги, и требуют некоторых пояснений. Системы Unix (включая Linux) содержат внутренний кэш дисковых блоков, который называется буферным кэшем (buffer cache). Когда возвращается системный вызов, данные, переданные операционной системе, были скопированы в буфер в буферном кэше. Они необязательно были записаны на диск.

Буферный кэш значительно повышает производительность: поскольку дисковый ввод/ вывод часто на порядок и медленнее операций центрального процессора и памяти, программы значительно снизили бы производительность, если бы им пришлось ждать завершения каждой записи на диск. Вдобавок, если данные были недавно записаны на диск, при последующем чтении тех же данных они уже находились бы в буферном кэше, откуда их можно вернуть немедленно, не дожидаясь завершения операции чтения с диска.

Системы Unix осуществляют также опережающее чтение; поскольку чтение в большинстве случаев последовательное, операционная система после прочтения одного блока осуществляет чтение нескольких дополнительных последовательных блоков таким образом, что эта информация будет уже находиться в кэше, когда программа ее запросит. Если один и тот же файл читают несколько программ, они все получают преимущество, поскольку все получают свои данные из одной копии дисковых блоков файла в буферном кэше.

Все это кэширование, конечно, замечательно, но бесплатного обеда не бывает. В то время, пока данные находятся в буферном кэше и до того, как они будут записаны на диск, есть небольшое, но вполне реальное окно, в котором может случиться катастрофа; например, если выключат питание. Современные дисковые приводы обостряют эту проблему: у многих из них есть собственные внутренние буферы, поэтому при записи данных на диск они могут оказаться не записанными на носитель при выключении питания! Это может быть значительной проблемой для небольших систем, которые не находятся в информационном центре с контролируемым энергоснабжением или не имеют источников бесперебойного питания (UPS).[50]

Для большинства приложений вероятность того, что данные в буферном кэше могут быть нечаянно потеряны, довольно низка. Однако, для некоторых приложений любой такой шанс неприемлем. Поэтому в системе Unix было введено понятие синхронного ввода/вывода, при котором программе гарантируется, что по возвращении из системного вызова данные безопасно записаны на физическое устройство хранения.

Флаг гарантирует целостность данных; данные и любая другая информация, которую операционная система должна найти, записываются на диск до возвращения. Однако, вспомогательные данные, такие, как время модификации или доступа к файлу, могут быть не записаны на диск. Флаг требует, чтобы эти данные также были записаны на диск до возвращения. (Здесь тоже нет бесплатного обеда; синхронные записи могут серьезно повлиять на производительность программы, заметно ее снизив.)

Флаг предназначен для чтения данных: если находит данные в буферном кэше, которые были назначены для записи на диск, функция не вернет эти данные до тех пор, пока они не будут записаны. Два других флага влияют на это: в частности, заставит ждать, пока не будут также записаны и вспомогательные данные.

 

ЗАМЕЧАНИЕ. Что касается ядра версии 2.4, Linux рассматривает все три флага одинаково со значением флага. Более того, Linux определяет дополнительные флаги, которые специфичны для Linux и предназначены для специального использования. Дополнительные подробности см. в справочной странице GNU/Linux для open (2).