Date: Mon, 31 Dec 2001 10:14:12 -0500 (EST) From: Matthew Emmerton <matt@gsicomp.on.ca> To: Mike Barcroft <mike@FreeBSD.ORG> Cc: Peter Pentchev <roam@ringlet.net>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <Pine.BSF.4.21.0112311009010.36668-100000@xena.gsicomp.on.ca> In-Reply-To: <20011231043633.E45114@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Dec 2001, Mike Barcroft wrote: > [Moved to -arch, BCC'd to -hackers.] > > Peter Pentchev <roam@ringlet.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0112311009010.36668-100000>