login
Search
Gordon Tetlow recently announced, "I just committed a patch to change /bin and /sbin from statically to dynamically linked." This change follows the NetBSD project which made the same switch a year ago September [story]. FreeBSD -current now has a /rescue directory that contains a small number of statically linked "rescue" binaries. Gordon goes on to note, "If you don't like the idea of using a dynamically linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your make.conf."
The two reasons for this change are to significantly shrink the /bin and /sbin directories (from 33 MB to 4 MB on i386), and proper support for FreeBSD's new name service switch (NSS) implementation. For a complete understanding of the latest filesystem structure, see the hier man page. Read on for Gordon's announcement and some of the resulting discussion.
From: Gordon Tetlow [email blocked] To: current Subject: HEADS UP: /bin and /sbin are now dynamically linked Date: Sat, 15 Nov 2003 21:10:28 -0800 I just committed a patch to change /bin and /sbin from statically to dynamically linked. If you don't like the idea of using a dynamically linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your make.conf. The reasons for doing so have been hashed over lots of times. But the short of it: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. 2) Proper support for NSS. This will finally allow you to use NSS modules and get things like usernames in ls -l working for modules that are dynamically loaded. -gordon
From: Robert M.Zigweid [email blocked] Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked Date: Sun, 16 Nov 2003 09:46:47 -0500 I'll admit to being mostly a lurker here, but isn't the point of /sbin to be statically linked. That's what the 's' stands for? Second question. This seems to imply that /sbin and /bin both have to have the same behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid
From: Richard Coleman [email blocked] Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked Date: Sun, 16 Nov 2003 11:22:36 -0500 rv:1.5) Gecko/20031007 Robert M.Zigweid wrote: > Second question. This seems to imply that /sbin and /bin both have to > have the same behavior? I have no problem with /bin being dynamically > linked, but what if I want /bin to be dynamic and /sbin static? I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or "ls". Statically linked binaries to fix a hosed system are now in /rescue. Check "man hier". Richard Coleman [email blocked]
From: Robert Watson [email blocked] Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked Date: Sun, 16 Nov 2003 12:06:36 -0500 (EST) On Sun, 16 Nov 2003, Richard Coleman wrote: > Robert M.Zigweid wrote: > > I'm not sure what that would accomplish. If a system was broken such > that the dynamically linked binaries in /bin didn't work, the utilities > in /sbin wouldn't be enough to fix the system. For instance, you > wouldn't have a shell or "ls". And these problems are best fixed through the new /rescue tree. I was pleasantly surprised to find that the net space consumed by 5.0-CURRENT in / for /stand, /sbin, and /bin was substantially larger in the statically linked world than the space required for / with /rescue, /sbin, and /bin in the dynamically linked world. I.e., I can now update boxes installed with smaller root file systems from earlier 4.x releases without running out of space, whereas before I would run out of space. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [email blocked] Network Associates Laboratories
version ?
I suppose these change will be in the next 5.x releases only (not in 4.x). Right ?
yea 5.x
yeah. -current, not -stable
it'll be in 5.2-RELEASE (it i
it'll be in 5.2-RELEASE (it is 5.1CURRENT presently)
5.2 is due out in december as par:
http://www.freebsd.org/releases/5.2R/schedule.html
's' in sbin = superuser?
I'll admit to being mostly a lurker here, but isn't the point of /sbin to be statically linked. That's what the 's' stands for?
I'm under the impression that the s stands for "superuser". So, sbin is for executables that are run only by the superuser(s) or root. I've noticed that, by default, /sbin is not in a normal user's path, but is in root's path.
I don't have a FreeBSD system available to me at the moment to confirm this. But in Linux and Solaris this appears to be true from looking at what's in the sbin directories.
s=system
I was always under the impression that "s" was for system.
/sbin/ explained
3.4 Directory Structure of the FreeBSD Handbook explains that /sbin/ is for "System programs and administration utilities fundamental to both single-user and multi-user environments." The difference between /bin/ and /sbin/ is that the former is for "user utilities" and the latter for "system & admin utilities".
(FreeBSD is not special in this regard -- it's Unix.)
links to posted thread
Why do you never provid links to the story?
There may be further posts in between or related posts there or whatever!
Without links to the mailinglist the stories need further investigations by the readers .
re: links to posted thread
I nearly always post links to the mailing list discussion. Look at the bottom of each article (including this one). "Archive of above thread"
thanks for your explanation
apologies for my comment, missed this links for quite a long time.
Any Security Issues?
Are there any security issues that this creates?
When I think of statically linked execs, The first think I think of is that someone can't just replace/delete a library and wreak havoc to the static bins. With dynamics, the possible avenues of foobarring a system is enhances somewhat.
No
Any attacker who can replace a system library can also replace the static binary. So there are no additional security issues.
Not so cut-and-dried
Yes and no. It's a matter of replacing one file, or relinking several. The window involved is different.
So while you're strictly correct, if you are attacking a system, you'll be more successful if you have to change fewer things and change them in a more mechanized manner. Replacing libc is easier than relinking multiple binaries in /bin or /sbin.