Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Unix BSD

/bin And /sbin Now Dynamically Linked In FreeBSD 172

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

/bin And /sbin Now Dynamically Linked In FreeBSD More

/bin And /sbin Now Dynamically Linked In FreeBSD

Comments Filter:
  • 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.
    • why not? /rescue/bin/mv /rescue/bin* /bin

      etc.

    • Did you read the summary? Static executables will be available in /recover (that's a new one on me.)

      But I don't understand this myself. /sbin means "static /bin" and it's that way for recovery purposes. Why make it dynamic and add a new directory to be the new statically linked recovery directory? This seems on the surface to just push the original problem back a step. Is the next new thing to be /srecover?

      • Re:Bad if not included with non-dyn executables (Score:5, Informative)

        by __past__ ( 542467 ) on Monday November 17, 2003 @09:27AM (#7492655)
        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)
        • I don't know when that came about but the early AT&T systems with dynamic linking used /sbin to mean static-bin. I think the s becaome overloaded early on and if your mounting a file system and have /bin/mount and /sbin/mount which one should the init script use? I think thats where the "s is for system" came into meaning.

    • Re:Bad if not included with non-dyn executables (Score:1, Interesting)

      by Anonymous Coward
      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.
    • It's pretty easy to have a couple of static tools on the system to fix things if an upgrade fails.

      I believe RH packages sash and busybox. They don't have any problem, and once, long ago, after borking up ld.so (worse than just libc), I had to use 'em to recover.

      How often do you have a libc upgrade fail, though, in this day of package managers and tested distributions?

      Another poster asked what the point of this is -- its memory savings.

  • Cool (Score:5, Insightful)

    by __past__ ( 542467 ) on Monday November 17, 2003 @09:22AM (#7492633)
    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 (Score:5, Informative)

      by rtaylor ( 70602 ) on Monday November 17, 2003 @09:31AM (#7492669) Homepage
      Indeed.. According to the schedule [freebsd.org] the tree is to be frozen today.
    • If (dynamic linked /bin and /sbin) + (statically linked /rescue) is smaller than the old statically linked /bin and /sbin, why not move /rescue into /bin and /sbin and reduce size even further?

      • Re:Cool (Score:5, Informative)

        by __past__ ( 542467 ) on Monday November 17, 2003 @10:02AM (#7492829)
        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.
        • Also, in theory, it makes upgrading easier, especiallly if there is a flaw or bug fix or some other _minor_ change in the library. Just drop in the library, and no need to recompile everything. In practice though, this does occasionally break stuff. (*cough glibc*)

    • Re:Cool (Score:5, Informative)

      by shlong ( 121504 ) on Monday November 17, 2003 @10:27AM (#7492934) Homepage
      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.
    • Static binaries, in cases where you want to run them somewhat rapidly (>100/s), are much, much faster than dynamic binaries.
      • When was the last time you thought to yourself, "hmm, I think ls is running too slow.."?

        Sure, for the 1% of FreeBSD users that actually thought that at one time, this is great. But wouldn't it make more sence for those users to just recompile their specific binaries, instead of forcing nearly all sane FreeBSD users to recompile their ENTIRE /bin and /sbin?

    • Re:Cool (Score:5, Insightful)

      by gnu-sucks ( 561404 ) on Monday November 17, 2003 @11:46AM (#7493595) Journal
      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.

    • Speed (Score:3, Informative)

      by dcs ( 42578 )
      Actually, no. Dynamically linked binaries are slower than statically linked ones.

  • Security advantage (Score:5, Insightful)

    by ebcdic ( 39948 ) on Monday November 17, 2003 @12:04PM (#7493747)
    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.
    • That is a very good point! I know many people who had been bitten by this a few times in the past. With fast machines, making the world every now and then is not such an obstacle as it used to be some years ago (security by recompiling). But sometimes, especially on colocated machines, applying a libc fix can still be a life-saver!

    • Re:Security advantage (Score:3, Informative)

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

      • "FreeBSD update" doesn't work for those of us tracking 5.x-RELEASE, and it only provides binary updates for the IA32 (i386-family) port.

        • FreeBSD Update doesn't care what you're running. But you're mostly right -- nobody is publishing updates for anything other than i386 4.(7|8|9)-RELEASE.

          In the near future (next week, maybe the week after) I'll start publishing updates for i386 5.x as well; non-i386 platforms... well, I haven't heard from anyone interested in using FreeBSD Update on those, so that will probably wait until FreeBSD Update becomes part of the base system (around 5.5-RELEASE, maybe?) and the Project takes on the task of buildi

          • What does it take to create binary updates? I'd be more than willing to build binary updates for FreeBSD/alpha 5.1-RELEASE on a soon-to-be-mine AlphaServer 2100.

            • Building updates requires a box which doesn't object to having its clock shifted forwards by 400 days from time to time. Having people use the updates you build requires that people trust you.

              When I get the code written -- which is probably going to be about a year from now -- that last requirement will be dropped, since it will be possible for several buildboxes to cross-verify and cross-sign. (This is the primary reason I'm keeping FreeBSD Update out of the base system for now.)

              But feel free to downlo

    • Re:Security advantage (Score:2, Interesting)

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

    • In my ever so humble opinion, what's in /bin and /sbin should be static, because it should be things required to boot, and those should have as few dependencies as possible. Everything a normal user should use should be in /usr, and that includes administrative tools and daemons.

      There's no reason not to have dynamic versions of everything that's in /bin in /usr/bin, and restrict /bin only to root. If you can't mount /usr you probably can't go multiuser and other users can't log in anyway.

  • Purpose of / (Score:3, Interesting)

    by martycombs ( 211319 ) on Monday November 17, 2003 @12:17PM (#7493860) Homepage

    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 / (Score:5, Informative)

      by Brandybuck ( 704397 ) on Monday November 17, 2003 @03:09PM (#7495531) Homepage Journal
      / - 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.
  • Didn't the Amiga Operating System do this nearly two decades ago?

    If not, how does this differ?

    • Re:Amiga (Score:3, Informative)

      by Brandybuck ( 704397 )
      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:Amiga (Score:4, Informative)

      by cant_get_a_good_nick ( 172131 ) on Monday November 17, 2003 @03:31PM (#7495736)
      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.

  • Isn't /sbin for static binaries? (Score:3, Interesting)

    by kriston ( 7886 ) on Monday November 17, 2003 @03:16PM (#7495610) Homepage Journal
    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

  • ummm... (Score:3, Interesting)

    by shaitand ( 626655 ) on Monday November 17, 2003 @07:14PM (#7497909) Journal
    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? (Score:4, Insightful)

    by siobHan ( 26220 ) on Monday November 17, 2003 @09:33PM (#7498863)
    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

Slashdot Top Deals

The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]

Close