Логическое обоснование. Объект действий над фай л а м и м ожно инициализировать с по м о щ ью упорядоченной пос л едовате л ьности операций close ()

Объект действий над фай л а м и м ожно инициализировать с по м о щ ью упорядоченной пос л едовате л ьности операций close (), dup2 () и open (), предназначенной д л я испо л ьзования функция м и posix_spawn () и л и posix_spawnp () с це л ью получения м ножества открытых фай л овых дескрипторов, унас л едованных порожденны м процессо м от своего родите л я, и м ею щ е г о собственное м ножество открытых фай л овых дескрипторов в м о м ент вызова функции posix_spawn () и л и posix_spawnp (). Д л я реор г анизации фай л овых дескрипторов бы л о пред л ожено о г раничиться то л ько операция м и close () и dup2 (), а для то г о, чтобы порожденный процесс получил «в наследство» открытые файлы, м ожно посгупить дву м я способа м и: либо заставить вызывающий процесс открывать их перед вызово м функции posix_spawn() или posix_spawnp() (и закрывать их пото м), либо передавать и м ена нужных файлов в порожденный процесс (в аргу м енте argv), чтобы он м ог их открыть са м остоятельно. Разработчики стандарта реко м ендовали использовать на практике один из этих двух способов, поскольку детализированный статус ошибки в случае сбоя при выполнении операции открытия файла всегда доступен для приложения. Но разработчики стандарта по следую щ и м причина м все же считают воз м ожны м разрешить включение в объект действий над файла м и операцию open.

1. Это согласуется с эквивалентной функциональностью библиотеки POSIX.5 (Ada).

2. Это поддерживает парадигму перенаправления потоков ввода-вывода, часто применяемую POSIX-программами, предназначенными для вызова из оболочки. Если такая программа является сыновним процессом, ее можно сориентировать на самостоятельное открытие файлов.

3. Это позволяет сыновнему процессу открывать файлы, которые не должен открывать родительский процесс, поскольку операция по открытию файлов в этом случае может оказаться неудачной или нарушить права доступа к файлам (или права собственности).

Относительно приведенного выше п. 2 заметим, что действие «открыть файл» создает для функций posix_spawn () и posix_spawnp () те же возможности, что и операторы перенаправления для функции system(), но только без промежуточного выполнения оболочки. Например, так: system («myprog < filel 3< file2»);

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

Кроме того, если родительский процесс выполняется из файла, для которого установлен бит режима «set-user-id» (идентификационный номер пользователя установлен) и в атрибутах порожденного процесса установлен флаг POSIX_SPAWN_RESETIDS, то файл, созданный в родительско м процессе, получит (воз м ожно, некорректно) в качестве владельца родительский ID эффективного пользователя, в то вре м я как файл, созданный действие м open() при выполнении функции posix_spawn() или posix_spawnp(), получит в качестве владельца реальный ID родительского процесса; при это м операция open, выполненнал родительски м процессо м, м ожет успешно открыть файл, к которо м у реальный пользователь не должен и м еть доступ, или неудачно открыть (т.е. не открыть) файл, к которо м у реальный пользователь должен и м еть доступ.