Dynamic /bin support on FreeBSD

Dan writes "Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system. He cautions that the patch is preliminary and should probably be installed on a test machine."

Comments

Re:hmm talkative bunch around here

[Otter]

The Slashdot writeup:

Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

The linked writeup:

Gordon Tetlow has put together a patch to have /bin dynamically linked on FreeBSD. This is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

The message itself:

I just hacked together support to have /bin dynamically linked. This is the first step on the way to having everything play nicely with nectar's work on getting NSS into the system.

Not much more to add, is there? Except that this is the first step on the way to having everything play nicely with ongoing work on getting NSS into the system.

Why?

[aridhol]

Why do they need to change the established way things work (statically linked in /bin, dynamically linked in /usr/bin) to add a new system? Why not either adapt NSS or install it in /usr?

Re:Why?

[Neil]

NSS (name service switch) provides "on the fly" reconfigurable name services - it is the mechanism that allows (for example) a Solaris or Linux machine to look up password entries in /etc/passwd, the NIS, LDAP, or whatever, depending on the contents of the "passwd:" line of /etc/nsswitch.conf.

NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

A system where some of the binaries obey preferences the admin expresses through /etc/nsswitch.conf but, say, /bin/ls doesn't is unlikely to be popular! :-)

Re:Why?

[R.Caley]

NSS works by dynamically loading the correct resolving routines from shared objects at run time. In contrast, a statically linked binary has "hard wired" name service lookup policies, which have been set by whatever library routines were statically linked into the executable.

This is, of course, not a sane justification. For example the resolver library quite happily obeys host.conf to control the same kind of decision about host name lookup dispite being statically linked into things. The highly sophisticeted answer is (shock) to have the library read the configiuration file.

Just Say No to ls(1) not working because your library path is in a mess. Not to mention making life for rootkits one step easier.

Re:Why?

[antis0c]

This is, of course, not a sane justification. For example not all resolver libraries bundled by default on the system, and applications certainly can't allow for all possible future resolver libraries. The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers. Those resolvers become dynamic libraries which would have to be load, gasp, dynamically.

If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of configuration file reading is going to solve this one smart guy. I one: either have to recompile everything in /bin, or two: the things in /bin will need to be dynamically linked.

Re:Why?

[R.Caley]

The purpose of NSS isn't just name resolution configuration, its to extend name resolution infinitely with new resolvers.

How many times in the past 10 years have you desperately needed to have /bin/ls look up passwords in some bizzare new way?

If my /bin stuff is statically linked, and I install a new resolver, then what? No amount of configuration file reading is going to solve this one smart guy. I one: either have to recompile everything in /bin,[...]

I build world maybe 4 or 5 times a year. That's infinitely more often than I decide I need a new way to lookup passwords (since I never have).

Re:Why?

[antis0c]

Well I'm glad your requirements permit that, so don't bother turning on the ability to dynamically link /bin. However not everyone's requirements are the same as yours so it's nice to have the ability. Also, Last time I checked, /bin didn't only contain 'ls'. Smart guy.

Re:Why?

[R.Caley]

Also, Last time I checked, /bin didn't only contain 'ls'.

So, how many times in the last 10 years have you needed to have /bin/cat look up passwords in a different way:-)

Why

[Anonymous Coward]

Who the hell needs this!?

Re:Why

[pmz]

Who the hell needs this!?

Some of the comments at the link in the article would suggest new or improved LDAP support. That's pretty significant. NSS stands for Name Service Switch, which allows alternative datasources for many of the databases traditionally stored in /etc.

Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database. Minus DNS, these datasources can also provide the users database, the RBAC databases, the automounter configuration, bootparams, to name a few. To say it is useful is an understatement.

Re:Why

[Piquan]

That's good for who needs this. As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.

So, my question is, why are /bin and /sbin traditionally static? Gordon's patch pretty much just sets them to dynamic linkage, and puts some libs and rtld in /lib. I'd think that if having /bin and /sbin dynamically linked was kosher, tho, that they would be. So I'm a little worried about this patch.

Re:Why

[pmz]

So, my question is, why are /bin and /sbin traditionally static?

Safety. When trying to repair a broken system, the dynamic linker and libraries become one less thing to worry about when the essential tools are staticly linked. I can't imagine that all the tools in /bin would need to be dynamic, so there's a good chance that many would remain static.

Re:Why

[aridhol]

/bin and /sbin need to be usable when only the root has been mounted. That means that they can't dynamically link to anything that's not in the root. That includes /usr/lib, which is where most dynamic linking takes place.

I don't know why they needed to be completely static, as /lib still exists, so they should be linkable with libraries in there.

It's probably just a safeguard against accidentally linking to a library in /usr/lib, just to have them fail when they're most needed.

Re:Why

[KeyserDK]

Linux has had this for ages?

Re:Why

[JDizzy]

Static because of the paranoia we have about libraries becoming corrupted. Consider this nightmare situation: Your computer panics, and in so it somehow gets a bit of filesystem corruption. You softboot, and discover that the FS corruption occurred in your libc and now all you dynamically linked executable that almost all of which link to libc are utterly useless. If fsck were dynamically linked it would be unable to examine/fix the file systems. That is why the /bin, and /sbin are all statically built, because these nightmares have happened before to some of use on other UNIX systems. WE do not dare to make that mistake on the most stable OS on earth! Also, what is somebody decided to put his libraries on /usr (mounted on its own filesystem), and have dynamically linked init on the root filesystem? The answer is the kernel wouldn't' be able to boot the system into single, or multi-user modes. There are many reasons to have static /bin and /sbin. On the other hand there are also a few reasons to not build them statically. Space is one major issue. The root filesystem would lessen in size dramatically if libc, and others, were not replicated into each executable. It would also open the door to more small version of FreeBSD that fit on floppies, and stuff. The only issue with dynamically linked /bin and /sbin is the need to fall back upon staticly built version of the same stuff in case your libs get corrupted. I think we might copy NetBSD and make a /rescue folder with crunched executables. Crunching is akin to compiling all your /bin and /sbin into one singulare binary file, and depending on how you invoke the binary, renders a different executable. Sorta like if I called crunch.bin as "fsck" it would bring the fsck code to the surface, or if the same crunch.bin were called as "ls" it would be ls. Inside the crunch.bin is dynamically linked , and archived executables. Hopefully that one file would not be damaged in fs corruption.

Re:Why

[pmz]

Linux has had this for ages?

I don't know much about FreeBSD and what it's current NSS capabilities are. This could be one of those things where Linux is stronger in some things but FreeBSD stronger in others. FreeBSD has a very good reputation, so I wouldn't expect the current limitations are show-stoppers.

Re:Why

[renehollan]

Hopefully that one file would not be damaged in fs corruption.

Holy light bulb, Batman! (well, JDizzy, any way, to give proper credit). You've just given me an idea!!

Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

Also, for sensitive dynamically linked libraries, perhaps the directory structure could be modified to have a common LD_LIBRARY_PATH for some system directories. Heck, never mind a mod: just make the loader sensitive to .ldpath symlinks in the directory of the executible.

Re:Why

[Anonymous Coward]

I personally like the idea of an option for a static build at the cost of the NSS functionality. As for the addition of the /rescue directory for dynamic builds, that sort of sucks but may be the safest thing to do for people concerned about stability. The odd thing about FreeBSD is that dynamic libraries have rarely been a show-stopper for me. By contrast, Windows users are far too familiar with "dll-hell". I've also had trouble with shared library versions in Slackware, but then Slackware probably isn't worth anybody's time anymore.

Re:Why

[JDizzy]

It would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

Re:Why

[sirket]

The odd thing about FreeBSD is that dynamic libraries have rarely been a show-stopper for me.

There are two reasons for this:

• FreeBSD does not screw around with the libraries in between releases.
  
• FreeBSD has always supported previous library versions.
  

The first point is self explanatory. As for their library mecahnisms: The last dozen or so times I have installed Linux, I have had to go on a treasure hunt to find exactly the right version of libc for a given application (Oracle, whatever). With FreeBSD, the old libraries can (and often are) installed and built with the system so you never have to hunt for them. Simply edit /etc/make.conf and include the libraries you need and you are done. Period.

FreeBSD libraries in make.conf also match the OS release so a 2.2 library is for a 2.2 kernel and program, etc. There is no guessing.

-sirket

Re:Why

[renehollan]

t would seem feasible to put chrunched binaries into the kernel itself, but that would be nasty kernel bloat!

Yes, at some point, SOMETHING has to work O.K. in order for the system to boot. But, that something should be small enough and the rest reliable and redundant enough to permit the critical piece to either live in ROM, or floppy.

Thought, bootable live CD distros are handy.

Still, the one time you most desperately need to repair a sick system is also going to be the time you don't have your Swiss-Army utility CD.

Re:Why

[aphor]

This is significant in that
1: the dynamic /bin utilities are JUST A TEMPORARY HACK, and that NSSWITCH will provide modular resolver support for important stuff like gethostbyname(3) among other things.
In case you haven't noticed, we need a way (LDAP?) to resolve IPSec host certificates by hostname/IP, and DNS isn't doing the job... IMHO.. other people have other reasons for wanting this.
2: dynamic linked /bin doesn't mean that everything is dynamic linked! You can static link everything, and dlopen(3) modules as you like.. falling back to a safe static function call if the .so is corrupted/gone. From FreeBSD-STABLE dlopen(3):

ELF executables need to be linked using the -export-dynamic option to
ld(1) for symbols defined in the executable to become visible to dlsym().

3: if you use dlopen(3) you can choose to use the ldconfig(8) hints or you can build a special secure .so and open it directly, bypassing the hints.

Re:Why

[JDizzy]

Right!

I'm all for a really small /rescue partition with crunched init, fsck, mount, sh, and a few other essential tools to recover a broken system. The kernel could be altered in such a way that if it couldn't mount the root file system, it could mount the /rescue FS, and the fsck could happen. This would be a FreeBSD (shoot me) "safe mode" of sorts.

If things were so broken that you couldn't fix them with the various built-in ways, a "rescue disk" (aka bootable cdrom, floppy) would have to be used to mount a pseudo root to in turn fsck the real root FS.

Re:Why

[realdpk]

Sure. The executables are small enough you could probably store them in a directory on each of your slices and each of your partitions in the slices. I like the idea, and I've taken advantage of it before when I couldn't mount / but I could convince the kernel to mount /usr as / in single user.

Re:Why

[42forty-two42]

Pssh. I'd just boot with linux init=/sbin/sash if my libs got corrupted.

Re:Why

[42forty-two42]

The last dozen or so times I have installed Linux, I have had to go on a treasure hunt to find exactly the right version of libc for a given application

There are only two versions of the libc ABI still widely used - libc.so.5 and libc.so.6. If your app requires a more specific version, override it. It'll work fine, IIRC.

Re:Why

[42forty-two42]

As for why, the NSS code works by dynamically loading the necessary backends. That's presumably why a dynamic /bin and /sbin are needed.

You could statically link all the libraries except libdl, if you really want static /bin and /sbin.

Re:Why

[KeyserDK]

True, i've only used nss to play around with winbind
in a win2k domain (samba3).

Pretty odd seing windows usernames with 'ls -l' =)

Re:Why

[parc]

There is no /lib in current FreeBSD systems. You have to create one to go along with this patch, and several dlls will be placed in it.

The only thing this realy gets you (other than NSS) is a smaller memory footprint at a (theoretical) cost in speed, as well as a little unsafeness in the case of one of your /lib libraries going bad.

And you've got to remember not to put /lib on a non-root mounted partition. No big deal there.

Re:Why

[realdpk]

Is glibc out of favor now then? I seem to remember having to have a few different versions of that laying around.

Re:Why

[42forty-two42]

Dunno, I just have: -rwxr-xr-x 1 root root 1104040 Mar 21 11:19 /lib/libc-2.3.1.so lrwxrwxrwx 1 root root 13 Apr 4 16:19 /lib/libc.so.6 -> libc-2.3.1.so

Re:Why

[Anonymous Coward]

Nothing in /rescue is dynamically linked:

$ file /rescue/init

/rescue/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for NetBSD, statically linked, stripped

$ ls -l /rescue/init

-r-xr-xr-x 127 root wheel 2564020 Mar 10 09:30 /rescue/init*

So we (NetBSD) impersonate 127 programs in /rescue.

Re:Why

[CoolVibe]

That's why, when this dynamic linking funnyness is going through, I want static versions of /bin and /sbin utils in /stand.

Re:Why

[JDizzy]

it really should be an option! Your right!

Re:Why

[yanestra]

Given that some executables are more important than others in reparing broken filesystems, this situation particularly exacerbated with crunched binaries, why not add error correcting codes to them, and use inteleaving techniques to mitigate single block errors? Yes, they would grow, but not likely to the limit of multiple complete copies.

Bit failures are very rare when having filesystem problems. ECCs only help with (single or multiple) bit failures. They don't help if the whole block is destroyed (which it is, after the hardware's own error correction system has failed).
Much more often it happens that the meta information of a filesystem got destroyed: You still have all your data, but you have no way to find them anymore.
The most useful way of protecting your data is an identical copy of it. That means: Backup or mirroring or duplicating (as of IBM lingo).

Re:Why

[yanestra]

Sure. The executables are small enough you could probably store them in a directory on each of your slices and each of your partitions in the slices. I like the idea, and I've taken advantage of it before when I couldn't mount / but I could convince the kernel to mount /usr as / in single user.

The problem is sitting in front of the terminal. It's absolutely no technical problem to have a partition somewhere containing all the data you need to get you system back to life if something very integral gets lost.
The problems are:

• deciding what is "all" you need,
• deciding where to put it so it doesn't get damaged,
• documenting the place so the person who needs it to fix a problem finds it,
• keeping it sync'ed so it can be used,
• but not too much sync'ed, so it doesn't copy your mistakes while administrating the system.

In my opinion, imitating the laisser-faire of the Linux folks doesn't help in doing everyday's administration job.
In my experience, the biggest problem with FreeBSD machines always has been finding some adequate tools to fix it when the system crashes after >2 years uptime- (Or do you have your FreeBSD 2.2 disk handy?)

Re:Why

[Eunuchswear]

Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.

And on a SVR4 system (like, for example Solaris):

$ ls -l /bin
lrwxrwxrwx 1 root sys 8 Jan 4 2002 /bin -> /usr/bin

So no problem with dynamicly linked /bin then :-)

Re:Why

[Axello]

Solaris, for example, can use local files, DNS, NIS, NIS+, and LDAP for the hosts database.

I didn't know that. MacOS X 10.2 uses a similar mechanism to look up system information, like hostnames, printers, users, groups, mountpoints. The information can reside in BSD-like /etc/ files, LDAP, NIS or SLP databases, or obtained via Rendezvous or SMB. The system finds the information it needs in the selected items. See the utility "Directory Access" for more (albeit minimal) info.

NSS = nsswitch

[Anonymous Coward]

I was wondering what it meant so I looked it up (http://www.freebsd.org/releases/5.1R/todo.html):

"NSSwitch support -- Jacques Vidrine (nectar@) --
Support for pluggable directory services using NSS, including adaptations of current directory services (local databases, NIS), and support for new services (LDAP, Active Directory, etc). This change has been committed, and requires broader testing."

One thing I had noticed that in -current I had to use nsswitch.conf to have it use dns rather than looking up my home-net's hostnames in the host file. This was still host.conf in -stable.

I believe other NIXes have had this for a long time, no?

Re:hmm talkative bunch around here

[Unregistered]

really i thought it was he first step on the way to having everything play nicely with nectar's work on getting NSS into the system. I guess i didn't really get it, then.

Debate over dynamic /bin

[evilcyber]

As evidenced by the messages already posted, the Dynamic/Static debate is probably going to rage on here. To see how this will likely all play out, take a look at the NetBSD mailing list archives regarding the Pro's and Con's. You'll also see some of the solutions that came up to the various issues. NetBSD has already gone through this flame war when they commited a dynamic root to their tree. (Noted buried in one of the threads.)

Re:Debate over dynamic /bin

[Anonymous Coward]

NetBSD went through the same "debate", with most of the objections coming from people who Fear Change, or had spurious objections which could be summarized as "Someone I know had a Linux/Solaris/... system with a fully dynamic userland and they got screwed once". NetBSD solved the latter problem by supplying a statically linked set of "recovery" tools under "/rescue".

A fully dynamically linked system has many advantages, and the justification for retaining the "/bin and /sbin is statically linked, /usr/* is dynamically linked" split is spurious at best, as that configuration was really just a limitation when shared libraries were first implemented.

Linux, Solaris and others have had a fully dynamically linked system for years, and its been successful overall, and the added enhancement of "/rescue" in NetBSD solves the main "how to recover" problem that the former have. If I recall correctly, part of the FreeBSD solution will be "/rescue" as well.

Luke.

(Color me biased; I did implement /rescue and the fully-dynamic changes in NetBSD ;-)

Re: Or do you have your FreeBSD 2.2 disk handy?

[Anonymous Coward]

Using any boot floppy or CD and restore (8) your last backup?