Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11393

Re: remaking bash, trying static, glibc refuses static...?

Show all headers | View raw

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?

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: remaking bash, trying static, glibc refuses static...? Linda Walsh <bash@tlinx.org> - 2015-08-18 21:41 -0700

csiph-web