Slashdot Mirror

← Back to Stories (view on slashdot.org)

/bin And /sbin Now Dynamically Linked In FreeBSD

Posted by timothy on from the seen-at-same-nightclub dept.

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."

5 of 172 comments (clear)

  1. Re:Bad if not included with non-dyn executables by Anonymous Coward · · Score: 1, Interesting

    Sir, several Linux distributions (such as Slackware) upgrade their libc's using dynamic /bin and /sbin, and without statically-linked package management tools (upgradepkg/makepkg/explodepkg/installpkg/removepk g). I would think it would be possible with FreeBSD as well.

  2. Purpose of / by martycombs · · Score: 3, Interesting

    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.

  3. Isn't /sbin for static binaries? by kriston · · Score: 2, Interesting

    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

    --

    Kriston

  4. ummm... by shaitand · · Score: 2, Interesting

    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?

  5. Re:Security advantage by neuroscr · · Score: 2, Interesting

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