/bin And /sbin Now Dynamically Linked In FreeBSD

Dan writes "Gordon Tetlow just committed a patch in FreeBSD current to change /bin and /sbin from statically to dynamically linked. The reason to do this is two-fold. This feature brings support for loadable PAM and NSS modules to base system utilities located in those directories. It also reduces the storage requirements for the root filesystem due to the use of shared libraries. This feature can be disabled in a buildworld by defining the Makefile (make.conf) variable WITHOUT_DYNAMICROOT. Note that statically-linked, crunched executables are available in the /rescue directory for use during system repair and recovery operations."

Comments

Re:Bad if not included with non-dyn executables

[JohnFluxx]

why not? /rescue/bin/mv /rescue/bin* /bin

etc.

Cool

[__past__]

Even with having statically linked versions of the tools needed for system repair in /rescue, the whole stuff still takes less place then before. So you really get the best of both worlds: The base system is smaller, more flexible and potentially even faster (has anybody measured it yet?), but static binaries are still around when you hosed you linker or libs.

I'm still somewhat surprised that this got committed now, shouldn't 5.2 be released Really Soon Now? This looks like something that ought to be tested in -CURRENT for a good while.

Re:Cool

[rtaylor]

Indeed.. According to the schedule the tree is to be frozen today.

Re:Cool

[__past__]

Because size is not the only reason for the dynamic /bin. One big reason was better support for dynamically loadable PAM/nsswitch modules in the base utilities - so there is a good reason to have multiple versions of some binaries, one that always works and one that can do more fancy stuff.

Re:Cool

[shlong]

I'm still somewhat surprised that this got committed now, shouldn't 5.2 be released Really Soon Now? This looks like something that ought to be tested in -CURRENT for a good while.

This is of course a very valid concern. It should be noted, however, that this was the last phase in the overall change. The 'heavy lifting' parts were done months ago (creating /rescue, moving libraries to /lib and /libexec). It also had been extensively tested by many developers, and was already an optional switch when building world.
In the end, we decided that a dynamic root filesystem was the future of 5.x, and that the 5.3 cycle was already overbooked with significant changes. We still have nearly a month before the release date of 5.2 to iron out any bugs. So after some final testing for a few days last week, I asked Gordon to Throw The Switch.

Re:Cool

[gnu-sucks]

if anything, there should be a /static. You see, 99% of all users will not see ANY improvement in this new scheme. It would be better to 'tack on' this idea as an option to the 2% user base that would actually use this to their advantage.

Do I really want to set my default shell to /rescue/sh and set all my important tools similarly? Heck no.

I want those users using PAM and whatnot to specify /static for THEIR SPECIFIC needs, and let the rest of the FreeBSD users maintain /bin and /sbin as they are, and should be.

This is sort of like an isp optomizing all connections for SNMP, because two users said it would be a good idea for what they do all day. And the isp tells all the other users, "well, we have an alternative dialup connection you can use, though its only at 9600, for better web browsing"

So sure, you can either 1) recompile FreeBSD, or 2) suffer the slings and arrows of /rescue.

Or, FreeBSD could just NOT BE STUPID OUT OF THE BOX.

Re:Bad if not included with non-dyn executables

[__past__]

But I don't understand this myself. /sbin means "static /bin" and it's that way for recovery purposes.

Wrong. man 7 hier:

/sbin/
system programs and administration utilities fundamental to both single-user and multi-user environments

Think "system administration", not "static". After all, /bin was static too, so the distinction doesn't much sense (and I think /sbin has been part of Unix earlier than dynamic linking anyway)

Re:Ant this news is ...

[torpor]

Of course it is.

How the /bin && /sbin binaries are treated in a release as significant as FreeBSD, is definitely news for nerds, stuff that matters.

The static nature of /sbin has been a significant issue in Unix-user/-admin land for many, many years. This change now sets in place a new scheme for administrators to understand and work around - with the new linking flag, admins can set up systems in new and interesting ways.

Any FreeBSD admin who now doesn't understand the reasoning and potential problems of this new linking scheme will *definitely* need to learn it and understand it if they want to continue doing a good admin job in the future.

One good way to learn about this and use it is to read the comments from slashdot readers about this issue ... and thus, this *IS* important news for slashdot.

Just because SCO/MICROSOFT/LINUX isn't in the article, doesn't mean its not important ...

Security advantage

[ebcdic]

One of the main advantages of this is that you can replace libraries with security loopholes without having to rebuild everything. There have been several cases of bugs in the standard libraries that have required the statically compiled programs in /bin to be rebuilt.

Re:Security advantage

[cperciva]

This isn't really a big deal -- if you don't want to rebuild things yourself, you can just use FreeBSD Update.

Re:Security advantage

[neuroscr]

and introduce them just as fast. Now you can hack all the binaries in one go wtihout a recompile...

Purpose of /

[martycombs]

I thought *nix was designed as:

/ - minimum required to boot and repair system

/usr - other binaries included on default distro

/usr/local or /opt - packages added above and beyond the distro

If your system ever became damaged, you booted to / and fixed it. If / is too large, then audit what's in there and make sure it contains the bare minimum required.

Adding /rescue is unnecessarily cluttering up the system.

Re:Purpose of /

[Brandybuck]

/ - minimum required to boot and repair system

It still is. /rescue is for repairing the system. /bin and /sbin are a comfortable but minimal set needed for booting.

While there may be stuff in /bin and /sbin you might never use, all of it is used by someone or another at boot, single or rescue time.

Re:The Editor war is over : Vim won!

[fsmunoz]

...With less and less distrobutions shipping emacs...

M-x ispell-buffer

Re:Amiga

[Brandybuck]

If not, how does this differ?

The difference is that the Amiga is dead, while FreeBSD is alive, well and kicking. FreeBSD could have done this way back in 1.0, but there was no pressing need to. In the immortal words of some anonymous software designer: "don't prematurely optimize."

Re:Bad if not included with non-dyn executables

[Brandybuck]

How often do you have a libc upgrade fail, though

In FreeBSD, never. In Linuxland, everytime GNU bumps the minor version of glibc. To be fair, the upgrade works fine. It's just that everything else on the system breaks.

Isn't /sbin for static binaries?

[kriston]

I thought one of the reasons we have /sbin is so that we can run the binaries there without having dynamic libraries involved.

Reasons being:

1) Size: Running in single-user mode or small kernels that don't use dynamically-linked libraries.

2) Security: No risk of library-path-based security exploits.

Am I missing something here? Why isn't /sbin statically-linked, anyway?

Kris

Re:Amiga

[cant_get_a_good_nick]

You don't understand the post. The point is not that FreeBSD is going boldly into the 80s with dynamic linking, it's that the default world now has binaries living in /bin and /sbin as dynamic instead of static. For a long time they were all static linked because of recovery issues. Now they are dynamically linked (with an option to be static if you're paranoid). They probably link against only stuff in /lib which will be on the root partition. Anything in /usr/lib would be dangerous if /usr was toasted - your shell would go bye bye.

ummm...

[shaitand]

okay, maybe it's just me, and maybe I'm wrong. But I was under the impression that /bin /sbin's primary reason for existance was the same hole this /rescue directory will be filling? And how does it use LESS space (as if space were an issue anymore compared to speed in which case static is USUALLY, not always, better anyway), to simply move the static versions of the binaries in /bin and /sbin to /rescue and add dynamic versions to /bin and /sbin.

Since /rescue now becomes as fundementally critical as /bin and /sbin have been before it certainly counts as part of the base system. If you move the static binaries, and add something, isn't that BIGGER than just the static binaries?

Did you actually try it?

[siobHan]

I wonder if anyone screaming about what a HORRIBLE idea this is and how it will cause cancer in kittens, has actually tried it? Obviously the FreeBSD developers are not dumb, and root will always be able to get on to use /rescue, and the advantages are a lot more sophisticated than just saving some space on the root partition.

It's pretty knee-jerk to scream about it if you don't actually know how it's been implemented.

J

Speed

[dcs]

Actually, no. Dynamically linked binaries are slower than statically linked ones.