Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: Re: remaking bash, trying static, glibc refuses static...? Date: Tue, 18 Aug 2015 21:41:08 -0700 Lines: 77 Approved: bug-bash@gnu.org Message-ID: References: <55D106B2.9000705@tlinx.org> <20150817044932.GB1584@vapier> <55D396EF.8030102@tlinx.org> <20150819031852.GU1584@vapier> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1439959279 7972 208.118.235.17 (19 Aug 2015 04:41:19 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <20150819031852.GU1584@vapier> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11393 Mike Frysinger wrote: > On 18 Aug 2015 13:34, Linda Walsh wrote: >> Then can you give any technical reason why a static >> lib that uses no network services (i.e. running >> on a mini-root ) couldn't be made available for >> the various calls that currently claim "dynamic library >> support" is necessary. > > (1) http://www.akkadia.org/drepper/no_static_linking.html --- I've seen this -- much of it not applicable to a miniroot recovery situation. However one of his issues is he lists as a benefit is 'Security'. With a statically linked binary you have no hope of waking up to a non-working system because new shared libraries have changed all the behaviors on your system. Just ask how many MS users have this problem. He mentions security fixes -- If my system is in single user, it's not likely that I need them. I *like[d]* the old-school method of putting static binaries in /bin and and using /usr/[s]bin alternatives after boot -- and after /usr is mounted. But now, with the "benefits" of shared libraries for /bin/mount and /sbin/xfs_restore being in /usr/lib64, when the system boots it can't mount anything. Lovely -- shared binaries -- hate them all the more with making mount use shared libs only located in /usr. Brilliant. Oh, yes, I can copy them to /lib64 -- but if they wanted to do a "root" and /usr (bin+lib) merge, why not put them in /[s]bin & /lib[64] and put the "compatibility symlinks" in the /usr dirs pointing at their corresponding root dirs. But with dynamic linking, they are putting binaries and libraries in /usr/ while leaving symlinks in the /bin & /lib dirs. Yup... dynamic linking -- beautiful concept being used by in all the wrong ways. > (2) it's using the nss system which lets people drop modules into the system > at anytime and change the overall lookups to use that. statically linking a > specific subset would block that ability. --- The linux kernel is a perfect example of a statically linked program that can dynamically load plugins to provide authorization data from external sources. Static doesn't mean you can't support 3rd party plugins/libs -- like LDAP. Tools like keyboard monitors, and background auditing would no longer work without LD_PRELOAD/PROFILE/AUDIT. Gee, now that's a shame. Most of my binaries I build shared -- I don't really care, but having a set of core binaries on a rescue partition makes sense. which means people using providers > like ldap would be stuck with static binaries that don't work. ---- Wrong -- the linux kernel is statically linked. It can use 3rd party security plugins for user auth & privs. > https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html ---- It's a description of how they did it to be opaque to users -- so developers, admins, hackers, crackers or law enforcement can easily put in new shivs in the next dynamic-lib update. Lovely. It Has happened with MS, you can't tell me it can't happen w/linux. > it's already been provided. build glibc w/--enable-static-nss. --- Funny, my distro must have forgotten that option... I wonder if glibc is as easy to build as the kernel?