From owner-freebsd-hackers Mon Dec 4 20:50:46 2000 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 4 20:50:42 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C8C7337B400; Mon, 4 Dec 2000 20:50:37 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA42777; Mon, 4 Dec 2000 21:50:13 -0700 (MST) (envelope-from ken) Date: Mon, 4 Dec 2000 21:50:13 -0700 From: "Kenneth D. Merry" To: Lyndon Nerenberg Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: PCIOCGETCONF/PCIOCREAD requires write permission? Message-ID: <20001204215013.B42689@panzer.kdm.org> References: <20001201174408.A17122@panzer.kdm.org> <200012030438.eB34cJm00619@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012030438.eB34cJm00619@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Sat, Dec 02, 2000 at 09:38:19PM -0700 Sender: ken@panzer.kdm.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Dec 02, 2000 at 21:38:19 -0700, Lyndon Nerenberg wrote: > >>>>> "Kenneth" == Kenneth D Merry 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). From your comments below, you apparantly don't have to have write access to do a copyin. I would like to have pciconf -l available for normal users, but my only hesitation is that there could be security implications. If we can get someone (i.e. a security type person) to check the PCIOCGETCONF code carefully for any potential problems, then we can enable it for normal users. The code wasn't written with security in mind, so I don't want to open it up to regular users without a security evaluation. If we can get that, then I don't see a problem with allowing read only access for that ioctl. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message