1POSIX_SPAWN_FILE_ACTIONS_ADDPCOLSOISXE(PPr)ogrammerP'OsSIMXa_nSuPaAlWN_FILE_ACTIONS_ADDCLOSE(P)
2
3
4

NAME

6       posix_spawn_file_actions_addclose,  posix_spawn_file_actions_addopen  -
7       add close or open action to spawn file actions object  (ADVANCED  REAL‐
8       TIME)
9

SYNOPSIS

11       #include <spawn.h>
12
13       int posix_spawn_file_actions_addclose(posix_spawn_file_actions_t *
14              file_actions, int fildes);
15       int posix_spawn_file_actions_addopen(posix_spawn_file_actions_t *
16              restrict file_actions, int fildes,
17              const char *restrict path, int oflag, mode_t mode);
18
19

DESCRIPTION

21       These  functions  shall add or delete a close or open action to a spawn
22       file actions object.
23
24       A spawn file  actions  object  is  of  type  posix_spawn_file_actions_t
25       (defined in <spawn.h>) and is used to specify a series of actions to be
26       performed by a posix_spawn() or posix_spawnp() operation  in  order  to
27       arrive  at the set of open file descriptors for the child process given
28       the set of open file descriptors of  the  parent.  IEEE Std 1003.1-2001
29       does  not  define  comparison  or  assignment  operators  for  the type
30       posix_spawn_file_actions_t.
31
32       A  spawn  file  actions  object,  when  passed  to   posix_spawn()   or
33       posix_spawnp(),  shall  specify how the set of open file descriptors in
34       the calling process is transformed into a set of potentially open  file
35       descriptors for the spawned process. This transformation shall be as if
36       the specified sequence of actions was performed exactly  once,  in  the
37       context  of  the spawned process (prior to execution of the new process
38       image), in the order in which the actions were  added  to  the  object;
39       additionally, when the new process image is executed, any file descrip‐
40       tor (from this new set) which has its  FD_CLOEXEC  flag  set  shall  be
41       closed (see posix_spawn() ).
42
43       The  posix_spawn_file_actions_addclose()  function  shall  add  a close
44       action to the object referenced by file_actions that  shall  cause  the
45       file  descriptor  fildes  to  be  closed (as if close( fildes) had been
46       called) when a new process is spawned using this file actions object.
47
48       The  posix_spawn_file_actions_addopen()  function  shall  add  an  open
49       action  to  the  object referenced by file_actions that shall cause the
50       file named by path to be opened (as if open(  path,  oflag,  mode)  had
51       been  called, and the returned file descriptor, if not fildes, had been
52       changed to fildes) when a  new  process  is  spawned  using  this  file
53       actions object. If fildes was already an open file descriptor, it shall
54       be closed before the new file is opened.
55
56       The   string   described   by   path   shall   be   copied    by    the
57       posix_spawn_file_actions_addopen() function.
58

RETURN VALUE

60       Upon  successful  completion, these functions shall return zero; other‐
61       wise, an error number shall be returned to indicate the error.
62

ERRORS

64       These functions shall fail if:
65
66       EBADF  The value specified by fildes is negative  or  greater  than  or
67              equal to {OPEN_MAX}.
68
69
70       These functions may fail if:
71
72       EINVAL The value specified by file_actions is invalid.
73
74       ENOMEM Insufficient  memory  exists  to  add  to the spawn file actions
75              object.
76
77
78       It shall not be considered an error for the fildes argument  passed  to
79       these  functions  to  specify a file descriptor for which the specified
80       operation could not be performed at the time  of  the  call.  Any  such
81       error will be detected when the associated file actions object is later
82       used during a posix_spawn() or posix_spawnp() operation.
83
84       The following sections are informative.
85

EXAMPLES

87       None.
88

APPLICATION USAGE

90       These functions are part of the Spawn option and need not  be  provided
91       on all implementations.
92

RATIONALE

94       A  spawn  file  actions object may be initialized to contain an ordered
95       sequence of close(), dup2(),  and  open()  operations  to  be  used  by
96       posix_spawn()  or  posix_spawnp()  to  arrive  at  the set of open file
97       descriptors inherited by the spawned process from the set of open  file
98       descriptors  in  the  parent  at  the  time  of  the  posix_spawn()  or
99       posix_spawnp() call.  It had been suggested that the close() and dup2()
100       operations alone are sufficient to rearrange file descriptors, and that
101       files which need to be opened for use by the  spawned  process  can  be
102       handled  either  by  having  the  calling  process open them before the
103       posix_spawn() or posix_spawnp() call (and  close  them  after),  or  by
104       passing  filenames to the spawned process (in argv) so that it may open
105       them itself. The standard developers recommend  that  applications  use
106       one of these two methods when practical, since detailed error status on
107       a failed open operation is always available  to  the  application  this
108       way.   However, the standard developers feel that allowing a spawn file
109       actions object to specify open operations is still appropriate because:
110
111        1. It is consistent with equivalent POSIX.5 (Ada) functionality.
112
113        2. It supports the I/O redirection paradigm commonly employed by POSIX
114           programs  designed  to be invoked from a shell. When such a program
115           is the child process, it may not be designed to open files  on  its
116           own.
117
118        3. It allows file opens that might otherwise fail or violate file own‐
119           ership/access rights if executed by the parent process.
120
121       Regarding 2. above, note that the spawn open file  action  provides  to
122       posix_spawn() and posix_spawnp() the same capability that the shell re‐
123       direction operators provide to system(), only without  the  intervening
124       execution of a shell; for example:
125
126
127              system ("myprog <file1 3<file2");
128
129       Regarding  3. above, note that if the calling process needs to open one
130       or more files for access by the spawned process, but  has  insufficient
131       spare  file descriptors, then the open action is necessary to allow the
132       open() to occur in the context of the child process  after  other  file
133       descriptors have been closed (that must remain open in the parent).
134
135       Additionally,  if  a parent is executed from a file having a "set-user-
136       id" mode bit set and the POSIX_SPAWN_RESETIDS flag is set in the  spawn
137       attributes,  a  file  created  within the parent process will (possibly
138       incorrectly) have the parent's effective user ID as its owner,  whereas
139       a   file   created   via  an  open()  action  during  posix_spawn()  or
140       posix_spawnp() will have the parent's real ID as its owner; and an open
141       by  the  parent  process may successfully open a file to which the real
142       user should not have access or fail to open a file to  which  the  real
143       user should have access.
144
145   File Descriptor Mapping
146       The  standard  developers  had originally proposed using an array which
147       specified the mapping of child file descriptors back to  those  of  the
148       parent.  It was pointed out by the ballot group that it is not possible
149       to reshuffle file descriptors arbitrarily in a  library  implementation
150       of  posix_spawn()  or  posix_spawnp() without provision for one or more
151       spare file descriptor entries (which simply may not be available). Such
152       an  array requires that an implementation develop a complex strategy to
153       achieve the desired mapping without  inadvertently  closing  the  wrong
154       file descriptor at the wrong time.
155
156       It  was  noted  by  a member of the Ada Language Bindings working group
157       that the approved Ada Language Start_Process family  of  POSIX  process
158       primitives use a caller-specified set of file actions to alter the nor‐
159       mal fork()/ exec semantics for inheritance of  file  descriptors  in  a
160       very  flexible  way,  yet  no such problems exist because the burden of
161       determining how to achieve the final file descriptor  mapping  is  com‐
162       pletely  on  the  application.  Furthermore,  although the file actions
163       interface appears frightening at first glance,  it  is  actually  quite
164       simple to implement in either a library or the kernel.
165

FUTURE DIRECTIONS

167       None.
168

SEE ALSO

170       close()      ,     dup()     ,     open()     ,     posix_spawn()     ,
171       posix_spawn_file_actions_adddup2() , posix_spawn_file_actions_destroy()
172       , posix_spawnp() , the Base Definitions volume of IEEE Std 1003.1-2001,
173       <spawn.h>
174
176       Portions of this text are reprinted and reproduced in  electronic  form
177       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
178       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
179       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
180       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
181       event of any discrepancy between this version and the original IEEE and
182       The Open Group Standard, the original IEEE and The Open Group  Standard
183       is  the  referee document. The original Standard can be obtained online
184       at http://www.opengroup.org/unix/online.html .
185
186
187
188IEEE/The Open Group                  2003 POSIX_SPAWN_FILE_ACTIONS_ADDCLOSE(P)
Impressum