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

10 of 172 comments (clear)

  1. Bad if not included with non-dyn executables by Creepy+Crawler · · Score: 1, Insightful

    The reason behind having /bin and /sbin as static linked is so that if you upgraded the libc and it failed, you still have a working system.

    Be aware that now with this syetm, you wont be able to mv the crunched static exec's to /bin or /sbin . With the old system, you didnt have to shut down to do a libc recovery. Now you do.

    Baaaad.

    --
    1. Re:Bad if not included with non-dyn executables by JohnFluxx · · Score: 2, Insightful

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

      etc.

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

      Fortunately, Linux is not prone to this exploitation. After reading the 10th SCO article of the day, the BSD administrator nodded knowingly and walked silently into the night....

  2. Cool by __past__ · · Score: 4, Insightful
    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.

    --
    Programming can be fun again. Film at 11.
    1. Re:Cool by gnu-sucks · · Score: 5, Insightful

      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.

  3. Re:Ant this news is ... by torpor · · Score: 5, Insightful

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

    --
    ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
  4. Re:Ant this news is ... by Jerf · · Score: 1, Insightful

    You do realize this was posted in the BSD section of Slashdot, right?

  5. Security advantage by ebcdic · · Score: 4, Insightful

    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.

  6. Re:Help me :) by Anonymous Coward · · Score: 1, Insightful

    How would you go about doing all this yourself in some Linux distribution?

    Just recompile all the system tools with dynamic linkage and you're done?

    Anyway, my root partition is only 20 Mb, and that's including root's home(not that there is anything there now...). Do I really have to?

    How do you get this into Linux? Why, do what they've been doing for years -- copy the BSD source, remove the copyright, and call it Linux.

  7. Did you actually try it? by siobHan · · Score: 4, Insightful

    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