diff options
| author | Alejandro Colomar <alx@kernel.org> | 2023-03-17 17:08:01 +0100 |
|---|---|---|
| committer | Alejandro Colomar <alx@kernel.org> | 2023-03-30 15:14:55 +0200 |
| commit | 4131356cdab8d37fc395ca5466a0401c8573380c (patch) | |
| tree | 8c4c6f1c3172358b735b481cbbfdd9cc04b00ed9 /man2/vfork.2 | |
| parent | fd00f831b52d61a91d59cb3b46182869145d9700 (diff) | |
| download | man-pages-4131356cdab8.tar.gz | |
man*/, man-pages.7: VERSIONS, STANDARDS, HISTORY: Reorganize sections
- Add a new HISTORY section that covers the history of an API, both
regarding implementations and regarding old standards. This was
previously covered in VERSIONS, and in some cases in STANDARDS.
- Repurpose VERSIONS to cover differing implementations in _current_
systems.
- STANDARDS is reduced to only cover current versions of standards.
That basically means only C11 (C99 has been superseeded by C11; C17
is just a bugfix of C11, so not really a new version), and
POSIX.1-2008 (*-2001 was superseeded by *-2008; *-2017 was just a
bugfix for *-2008). The section also mentions for example 'Linux',
'GNU' or 'BSD' when a non-standard API is Linux- or GNU-only or if
it's (de-facto) standard in the BSDs.
- In some cases content that should go into one of these sections was
in NOTES. Move it from there to where it corresponds.
- In the SYNOPSIS, I added [[deprecated]] in some functions that I
found are deprecated by the relevant standards.
- A few other related changes...
Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Diffstat (limited to 'man2/vfork.2')
| -rw-r--r-- | man2/vfork.2 | 92 |
1 files changed, 47 insertions, 45 deletions
diff --git a/man2/vfork.2 b/man2/vfork.2 index 5e6b8226c3..3a65010cab 100644 --- a/man2/vfork.2 +++ b/man2/vfork.2 @@ -134,11 +134,7 @@ The use of was tricky: for example, not modifying data in the parent process depended on knowing which variables were held in a register. -.SH STANDARDS -4.3BSD; POSIX.1-2001 (but marked OBSOLETE). -POSIX.1-2008 removes the specification of -.BR vfork (). -.PP +.SH VERSIONS The requirements put on .BR vfork () by the standards are weaker than those put on @@ -149,7 +145,7 @@ remaining blocked until the child either terminates or calls .BR execve (2), and cannot rely on any specific behavior with respect to shared memory. .\" In AIXv3.1 vfork is equivalent to fork. -.SH NOTES +.PP Some consider the semantics of .BR vfork () to be an architectural blemish, and the 4.2BSD man page stated: @@ -205,44 +201,6 @@ in this scenario requires either committing an amount of memory equal to the size of the parent process (if strict overcommitting is in force) or overcommitting memory with the risk that a process is terminated by the out-of-memory (OOM) killer. -.\" -.SS Caveats -The child process should take care not to modify the memory in unintended ways, -since such changes will be seen by the parent process once -the child terminates or executes another program. -In this regard, signal handlers can be especially problematic: -if a signal handler that is invoked in the child of -.BR vfork () -changes memory, those changes may result in an inconsistent process state -from the perspective of the parent process -(e.g., memory changes would be visible in the parent, -but changes to the state of open file descriptors would not be visible). -.PP -When -.BR vfork () -is called in a multithreaded process, -only the calling thread is suspended until the child terminates -or executes a new program. -This means that the child is sharing an address space with other running code. -This can be dangerous if another thread in the parent process -changes credentials (using -.BR setuid (2) -or similar), -since there are now two processes with different privilege levels -running in the same address space. -As an example of the dangers, -suppose that a multithreaded program running as root creates a child using -.BR vfork (). -After the -.BR vfork (), -a thread in the parent process drops the process to an unprivileged user -in order to run some untrusted code -(e.g., perhaps via plug-in opened with -.BR dlopen (3)). -In this case, attacks are possible where the parent process uses -.BR mmap (2) -to map in code that will be executed by the privileged child process. -.\" .SS Linux notes Fork handlers established using .BR pthread_atfork (3) @@ -268,7 +226,13 @@ specified as: CLONE_VM | CLONE_VFORK | SIGCHLD .EE .in -.SS History +.SH STANDARDS +None. +.SH HISTORY +4.3BSD; POSIX.1-2001 (but marked OBSOLETE). +POSIX.1-2008 removes the specification of +.BR vfork (). +.PP The .BR vfork () system call appeared in 3.0BSD. @@ -286,6 +250,44 @@ until Linux 2.2.0-pre6 or so. Since Linux 2.2.0-pre9 (on i386, somewhat later on other architectures) it is an independent system call. Support was added in glibc 2.0.112. +.\" +.SH CAVEATS +The child process should take care not to modify the memory in unintended ways, +since such changes will be seen by the parent process once +the child terminates or executes another program. +In this regard, signal handlers can be especially problematic: +if a signal handler that is invoked in the child of +.BR vfork () +changes memory, those changes may result in an inconsistent process state +from the perspective of the parent process +(e.g., memory changes would be visible in the parent, +but changes to the state of open file descriptors would not be visible). +.PP +When +.BR vfork () +is called in a multithreaded process, +only the calling thread is suspended until the child terminates +or executes a new program. +This means that the child is sharing an address space with other running code. +This can be dangerous if another thread in the parent process +changes credentials (using +.BR setuid (2) +or similar), +since there are now two processes with different privilege levels +running in the same address space. +As an example of the dangers, +suppose that a multithreaded program running as root creates a child using +.BR vfork (). +After the +.BR vfork (), +a thread in the parent process drops the process to an unprivileged user +in order to run some untrusted code +(e.g., perhaps via plug-in opened with +.BR dlopen (3)). +In this case, attacks are possible where the parent process uses +.BR mmap (2) +to map in code that will be executed by the privileged child process. +.\" .SH BUGS Details of the signal handling are obscure and differ between systems. The BSD man page states: |