Re: pciconf -lv - /dev/pci error

From: Robert Watson (rwatson_at_freebsd.org)
Date: 12/31/03

  • Next message: Peter Dufault: "Re: logitech cordless optical mouse problems..."
    Date: Wed, 31 Dec 2003 13:01:06 -0500 (EST)
    To: William Michael Grim <wgrim@siue.edu>
    
    

    On Wed, 31 Dec 2003, William Michael Grim wrote:

    > I have 5.1-RELEASE installed on my system, and I've never needed to do a
    > "pciconf -lv" to probe the system before. However, I tried doing it
    > earlier today after logging in through SSH and doing "su -" to become
    > superuser. I received this error:
    >
    > [root@snow 09:12:42 root]# pciconf -lv
    > pciconf: /dev/pci: Operation not permitted
    >
    > [root@snow 09:15:41 root]# ls -l /dev/pci
    > crw-r--r-- 1 root wheel 251, 0 Nov 2 05:09 /dev/pci
    >
    > So, as you can see, the permissions are correct. Perhaps I don't have
    > something compiled into my kernel? I can attach a dmesg and kernel
    > config if it's necessary.

    pciconf -lv appears to cause pciconf to open /dev/pci writable:

       731 pciconf CALL open(0x8049a55,0x2,0)
       731 pciconf NAMI "/dev/pci"
       731 pciconf RET open -1 errno 13 Permission denied

    And, of course, it's not writable by non-root. The attached patch causes
    pciconf to open /dev/pci read-only when listing devices (apply to
    usr.sbin/pciconf/pciconf.c):

    Index: pciconf.c
    ===================================================================
    RCS file: /home/ncvs/src/usr.sbin/pciconf/pciconf.c,v
    retrieving revision 1.19
    diff -u -r1.19 pciconf.c
    --- pciconf.c 20 Jun 2003 23:59:25 -0000 1.19
    +++ pciconf.c 31 Dec 2003 17:58:45 -0000
    @@ -165,7 +165,7 @@
             if (verbose)
                     load_vendors();
     
    - fd = open(_PATH_DEVPCI, O_RDWR, 0);
    + fd = open(_PATH_DEVPCI, O_RDONLY, 0);
             if (fd < 0)
                     err(1, "%s", _PATH_DEVPCI);
     

    The pci_user.c code in the kernel requires that the caller hold a writable
    file descriptor for most of the ioctls; the exception is PCIOCGETCONF,
    which is the only ioctl pciconf's list_devs() uses. We can probably just
    go ahead and commit this patch, I think. The reason a check was added to
    the kernel pci ioctl code is that unaligned writes to /dev/pci can cause
    faults, I believe...

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: Peter Dufault: "Re: logitech cordless optical mouse problems..."

    Relevant Pages

    • Re: whats next for the linux kernel?
      ... `ls -l' can show you the complete permissions of a lot of files in a few ... permission and some of the inheritees' permissions might suddenly make ... including UTF-8 canoncalization code, inside the kernel. ... complex and thus, when they *do* fail, the failures are correspondingly ...
      (Linux-Kernel)
    • Re: Sleeping thread not receive signal until it wakes up
      ... of the thread will keep calling IOCTL to get information from the ... kernel and will be blocked if there is no new information. ... and register a SIGALRM handler in the thread by using sigaction. ... the ISR routine when interrupt happens, ...
      (Linux-Kernel)
    • Re: Sleeping thread not receive signal until it wakes up
      ... >>> of the thread will keep calling IOCTL to get information from the ... >>> kernel and will be blocked if there is no new information. ... >>> and register a SIGALRM handler in the thread by using sigaction. ...
      (Linux-Kernel)
    • Re: Sleeping thread not receive signal until it wakes up
      ... of the thread will keep calling IOCTL to get information from the ... kernel and will be blocked if there is no new information. ... and register a SIGALRM handler in the thread by using sigaction. ...
      (Linux-Kernel)
    • ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)
      ... > no-new IOCTL policy certainly came as a surprise to the authors. ... operation" interface. ... a block driver is nothing but a message queue. ... kernel now for generic event delivery. ...
      (Linux-Kernel)