[Bug 99911] New: ioperm is kept on fork

[Bug 99911] New: ioperm is kept on fork

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

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

            Bug ID: 99911
           Summary: ioperm is kept on fork
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
          Reporter: alexhenrie24-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
        Regression: No

Created attachment 179851
  --> https://bugzilla.kernel.org/attachment.cgi?id=179851&action=edit
fork-and-beep test program

`man ioperm` currently states "Permissions are not inherited by the child
created by fork(2); following a fork(2) the child must turn on those
permissions that it needs." This is not true. I do not know if it was true at
some point in the past, but ioperm is preserved across a fork at least as far
back as Linux 2.6.26.

A test program to demonstrate this behavior is attached.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 99911] ioperm is kept on fork

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

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

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--- Comment #1 from Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
(In reply to Alex Henrie from comment #0)
> Created attachment 179851 [details]
> fork-and-beep test program
> 
> `man ioperm` currently states "Permissions are not inherited by the child
> created by fork(2); following a fork(2) the child must turn on those
> permissions that it needs." This is not true. I do not know if it was true
> at some point in the past, but ioperm is preserved across a fork at least as
> far back as Linux 2.6.26.
> 
> A test program to demonstrate this behavior is attached.

So, there's two possibilities here. Either the man page has always been wrong,
or once it was right, and then in the distant past things changed. I suspect
that the latter is more likely, but I could be wrong. If the latter is the
case, then even if we can't easily work out when the change occurred, it would
probably be nice to have a note in the page saying that once upon a time the
behavior was different.

With that in mind, could I ask you a favor. Could you take a quick look at the
Linux 1.0 sources (https://www.kernel.org/pub/linux/kernel/v1.0/ ). If I am
reading them correctly, then indeed back then the man page text was true. I am
looking at sys_ioperm() in kernel/ioport.c:

asmlinkage int sys_ioperm(unsigned long from, unsigned long num, int turn_on)
{
...
        set_bitmap((unsigned long *)current->tss.io_bitmap, from, num,
!turn_on);
        return 0;
}

and sys_fork() in kernel/fork.c:

asmlinkage int sys_fork(struct pt_regs regs)
{
...
        p->tss.bitmap = offsetof(struct tss_struct,io_bitmap);
        for (i = 0; i < IO_BITMAP_SIZE+1 ; i++) /* IO bitmap is actually SIZE+1
*/
                p->tss.io_bitmap[i] = ~0;
...
}

That latter piece code appears to be resetting the map in the child, but
perhaps I am misreading.

Thanks,

Michael

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 99911] ioperm is kept on fork

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

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

--- Comment #2 from Alex Henrie <alexhenrie24-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
I used QEMU to test Slackware 8.0,[1] which included both Linux 2.2.19 and
Linux 2.4.5. On 2.2.19, ioperm is lost on fork, but on 2.4.5, ioperm is kept on
fork. My guess is that the behavior changed in 2.4.0.

[1]
http://slackware.cs.utah.edu/pub/slackware/slackware-8.0-iso/slackware-8.0-livefs-d2.iso

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 99911] ioperm is kept on fork

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

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

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |CODE_FIX

--- Comment #3 from Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
Alex, sorry for the long delay in following up.

I have applied the patch below. Closing this bug.

Cheers,

Michael


diff --git a/man2/ioperm.2 b/man2/ioperm.2
index 91d081c..6171e1c 100644
--- a/man2/ioperm.2
+++ b/man2/ioperm.2
@@ -63,11 +63,9 @@ system call had to be used (with a
 argument of 3).
 Since Linux 2.6.8, 65,536 I/O ports can be specified.

-Permissions are not inherited by the child created by
-.BR fork (2);
-following a
+Permissions are inherited by the child created by
 .BR fork (2)
-the child must turn on those permissions that it needs.
+(but see NOTES).
 Permissions are preserved across
 .BR execve (2);
 this is useful for giving port access permissions to unprivileged
@@ -107,6 +105,10 @@ The
 .I /proc/ioports
 file shows the I/O ports that are currently allocated on the system.

+Before Linux 2.4,
+permissions were not inherited by a child created by
+.BR fork (2).
+
 Glibc has an
 .BR ioperm ()
 prototype both in

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html