Date: Sat, 02 Dec 2000 21:38:19 -0700 From: Lyndon Nerenberg <lyndon@orthanc.ab.ca> To: "Kenneth D. Merry" <ken@kdm.org> Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Message-ID: <200012030438.eB34cJm00619@orthanc.ab.ca> In-Reply-To: Your message of "Fri, 01 Dec 2000 17:44:08 MST." <20001201174408.A17122@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Kenneth" == Kenneth D Merry <ken@kdm.org> writes:
>> Is there any reason why the FWRITE test cannot/should not be
>> moved down into the 'case PCIOCWRITE' part of the switch? This
>> would make both PCIOCGETCONF and PCIOCREAD work for readonly
>> access to /dev/pci (which seems to me to be saner behaviour).
Kenneth> At least with the PCIOCGETCONF, you need write
Kenneth> permission, because it copies in patterns to match
Kenneth> against.
Does that have to equate with write access? Since you aren't changing
anything (device-wise) it seems this should be a read-only thing (even
though you're actually writing into the kernel memory arena).
Kenneth> As for PCIOCREAD, it only allows reading of PCI
Kenneth> registers, so the question there is whether there are any
Kenneth> potential security implications to allowing non-root
Kenneth> users to read PCI registers. If reading configuration
Kenneth> registers caused performance degredation, for instance.
Yup, this dawned on me later. Meanwhile, though, I've been running with
the read-only PCIOCGETCONF patch I suggested and I haven't seen any
problems with it after close to a week of use. I've submitted that
version as a pair of pr's (one for the kernel, and one for pciconf).
--lyndon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012030438.eB34cJm00619>