From owner-freebsd-security Mon Apr 20 06:31:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19191 for freebsd-security-outgoing; Mon, 20 Apr 1998 06:31:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19177 for ; Mon, 20 Apr 1998 13:31:34 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id VAA04518; Mon, 20 Apr 1998 21:24:28 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201324.VAA04518@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Murray cc: "Jordan K. Hubbard" , Wes Peters , Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Mon, 20 Apr 1998 10:14:25 +0200." <199804200814.KAA09666@greenpeace.grondar.za> Date: Mon, 20 Apr 1998 21:24:27 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Mark Murray wrote: > "Jordan K. Hubbard" wrote: > > > What do you do when passwd.conf specifies and encryption format you don't > > > have installed? Can FreeBSD programs fail gracefull to bind to a shared > > > library? I've never probed *that* deeply into shared libraries. :^) > > > > Sure. Man dlopen(3). Something which just selectively bound to > > either libm5crypt or libdescrypt or libfoocrypt based on the request > > would be kind of neat. It might solve problems elsewhere as well in > > terms of eliminating some of the existing symlink hackfixes.. > > This will need to work if the binary is statically linked as well. I > am not sure if dlopen is up to te task yet. There is no real reason why we can't work towards compiling libraries differently for static vs. dynamic. libcrypt could dlopen() an extensible backend when linked dynamic, while the static libcrypt could just contain all the presently known algorithms and the dlopen() stuff stubbed out. Static linking really does restrict some of the creative things that can be done with dynamic linking. It would fix the two different versions of init for starters... But that'd mean creating a /lib (and /libexec/ld.so) and putting a selection of shared libs in there. As long as ld.so was robust enough to work without /var/run/ld.so.cache, this would not be a problem. Putting a selection (say 2MB) of shared libs in /lib would probably cut the 9.5MB of /bin+/sbin to 3MB tops, leaving an overall root fs space saving. But we'd also be able to use things like PAM (heaven forbid), runtime selection of gethostbyname() backends (files,DNS,NIS,whatever). The removal of the files,dns,nis stuff (into a seperate library each) could save overall libc.so size. Adding NIS+ support would be as simple as adding one line to a file and everything could support it automatically without relinking etc. Same thing for new crypt routines for passwd stuff. However, the thought of having ld.so on / and a dynamic sh and init seems to make some people break out into a cold sweat... > M Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message