Re: Statically linked binary & NSS

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: Thu, 3 Dec 1998 16:12:27 -0500
> From: Roland McGrath <roland@frob.com>
> Cc: Cristian Gafton <gafton@redhat.com>, GNU libc hacker <libc-hacker@gnu.org>

> > Think about this: NSS cannot be static.  It simply does not work.
> > Never will.  So statically linked programs will behave differently
> > than dynamically linked programs.
> 
> Yes, they will use a link-time static set of NSS modules just like they use
> a link-time set of libc code.

But why would you ever want to do this (on a fully supported system,
not on a system that is static-only or some such)?

The one reason that people have quoted is that installation programs
should be linked statically, presumably so that people who kill their
libc.so or libnss_* have a chance to get back.  But this is wrong for
two reasons:

- if you manage to kill libc.so, your shell and the init, login,
  ifconfig, etc. binaries won't work.  You don't want to link them all
  statically.  You would particularly not want to link login using
  static NSS!
- most installation programs allow the packager to specify the owner
  and group of files they create.  So what happens if a user like
  'ftp' or 'httpd' or even 'nobody' is shared with other systems using
  something weird like DCE?  The installer would not work.

On my system, I have gone to some trouble to make sure my installation
program and ldconfig are linked _dynamically_.  This is so I can use a
LD_PRELOAD library to override their behaviour under certain
circumstances.  This would not be possible if they were linked
statically.  It also saved me from having a broken installation
program when I deleted the libnss_*.so.1 shared libraries.  It has
never caused a problem; if I install a broken libc.so, I use sln to
recover, in my running shell, or failing that (it's never happened) I
would boot off CD or my second hard drive.

Should static programs also have a hardcoded copy of /etc/passwd,
/etc/rpcservices, /etc/hosts, and so on?  This would make them truly
standalone, at the cost of zero flexibility.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>