Bug 13359

The manual page io(4) indicates that the entire access control to
port IO permission is handled by the file access permissions of
/dev/io.  This is incorrect, as the code seems also to care about
the actual process credentials.  Granting read permission to /dev/io
does not effectively grant IO priviledges to non-root processes.

Fix: 

Correct io(4) or remove the suser() check in mem.c
How-To-Repeat: 
Running 3.2-RELEASE I encountered this, that I thought was weird:

gardner@bongo=> id
uid=300(gardner) gid=20(staff) groups=20(staff), 0(wheel)

gardner@bongo=> ls -l /dev/io
crw-rw----  1 root  wheel    2,  14 Jul 11 14:05 /dev/io

gardner@bongo=> cat /dev/io
cat: /dev/io: Operation not permitted

su-2.02# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys),
4(tty), 5(operator), 20(staff), 31(guest)

su-2.02# cat /dev/io
cat: /dev/io: Device not configured

"Device not configured" is the expected result.

The manual page io(4) still tells me:

     The entire access control is handled by the file access
     permissions of /dev/io, so care should be taken in granting
     rights for this device.  Note that even read/only access will
     grant the full I/O privileges.

Which isn't true.  In fact the code in mem.c is checking my process
credentials as well:

          case 14:
                error = suser(p->p_ucred, &p->p_acflag);
                if (error != 0)
                        return (error);
                if (securelevel > 0)
                        return (EPERM);
                curproc->p_md.md_regs->tf_eflags |= PSL_IOPL;

(I also think that reading /dev/io should give me EOF, not ENXIO)