iopl.2: Permissions are not inherited across fork(2) or preserved on execve(2)

See https://bugzilla.kernel.org/show_bug.cgi?id=99901

Reported-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-03-15 16:25:07 +13:00
parent 33fd2d00f1
commit 38931a4d3c
1 changed files with 14 additions and 3 deletions

View File

@ -53,10 +53,11 @@ In addition to granting unrestricted I/O port access, running at a higher
I/O privilege level also allows the process to disable interrupts.
This will probably crash the system, and is not recommended.
Permissions are inherited by
Permissions are not inherited by the child process created by
.BR fork (2)
and
.BR execve (2).
and are not preserved across
.BR execve (2)
(but see NOTES).
The I/O privilege level for a normal process is 0.
@ -97,6 +98,16 @@ Glibc2 has a prototype both in
and in
.IR <sys/perm.h> .
Avoid the latter, it is available on i386 only.
Prior to Linux 3.7,
on some architectures (such as i386), permissions
.I were
inherited by the child produced by
.BR fork (2)
and were preserved across
.BR execve (2).
This behavior was inadvertently changed in Linux 3.7,
and won't be reinstated.
.SH SEE ALSO
.BR ioperm (2),
.BR outb (2),