Date: Mon, 20 Apr 1998 21:24:27 +0800 From: Peter Wemm <peter@netplex.com.au> To: Mark Murray <mark@grondar.za> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Wes Peters <softweyr@xmission.com>, Penisoara Adrian <ady@warpnet.ro>, freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Message-ID: <199804201324.VAA04518@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 20 Apr 1998 10:14:25 %2B0200." <199804200814.KAA09666@greenpeace.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804201324.VAA04518>