From owner-freebsd-arch Mon Dec 31 7:24:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts19-srv.bellnexxia.net (tomts19.bellnexxia.net [209.226.175.73]) by hub.freebsd.org (Postfix) with ESMTP id DFC2837B41B; Mon, 31 Dec 2001 07:24:15 -0800 (PST) Received: from xena.gsicomp.on.ca ([199.243.148.182]) by tomts19-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011231152415.WZUB9690.tomts19-srv.bellnexxia.net@xena.gsicomp.on.ca>; Mon, 31 Dec 2001 10:24:15 -0500 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fBVFECH36688; Mon, 31 Dec 2001 10:14:13 -0500 (EST) (envelope-from matt@xena.gsicomp.on.ca) Date: Mon, 31 Dec 2001 10:14:12 -0500 (EST) From: Matthew Emmerton To: Mike Barcroft Cc: Peter Pentchev , Mike Smith , arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) In-Reply-To: <20011231043633.E45114@espresso.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 31 Dec 2001, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev writes: > > Okay, so it's not documented in the manual, but one look at the source > > should suffice :) > > :( > > > As Mike said, there is a search path. However, the current directory > > is tried first. If a file by that name is not found in the current > > directory, the search path is, well, searched ;) The search path > > is available in the kern.module_path sysctl or in the output of > > 'kldconfig -r'. > > Oh no, it's worse than I feared. > > > This is similar to what shells have been doing for decades, with > > the added feature of an implicit '.' at the start of the search path. > > Yes, the usual approach shells take is much better designed. > > Here's how I would design this interface: > o _kldload(2) accepts a file path (similar to open(2)) > o kldunload(2) accepts a filename (no path) > o kldload(3) accepts a module name (procfs), file name (procfs.ko), or > file path (/boot/kernel/procfs.ko). > o Search paths for kldload(3) are controlled by the environment > variable `KLDPATH' (similar to MANPATH and PATH). > o When kldload(3) locates a module file, it calls _kldload(2). > o kldload(8) uses kldload(3) > o kldunload(8) uses kldunload(2) > > The main advantage of this design is that it allows a Unix programmer > to utilize it. :) Doesn't using an environment variable (KLDPATH) introduce all of the issues surrounding the use of LD_LIBRARY_PATH on Solaris and other OSes? While it's not the same issues (KLDs vs shared libraries), it still introduces the possibility of interesting exploits and problems, especially for installations that load as much as possible from KLDs. With the search path controlled by a sysctl, you have to be root to change it. With an environment variable, Joe User could blow it away, and then hammer the help desk with cries of "why can't I mount my floppy/cdrom" or "my sound card doesn't work" or "PPPoE doesn't work" - all because of a bogus KLD search path. I would think that using the root-controlled sysctl first, then using the user-controlled KLDPATH second would be a less error-prone setup. Please cc me since I'm not on arch-. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message