Unfortunate dynamic linking for everything

Robert Watson rwatson at freebsd.org
Wed Nov 19 13:00:38 PST 2003

On Thu, 20 Nov 2003, Bruce Evans wrote:

> On Wed, 19 Nov 2003, Marcel Moolenaar wrote:
> > set init_path=/rescue/init
> If dynamic root were ready to be turned on, then /rescue/init would be
> in the default init_path. 

The fallback path only works if the exec() fails cleanly without actually
starting the userspace code.  Peter and I have been talking about
improving failure mode handling by having rtld return a special error code
if (getpid() == 1 && oops_shlib_problem) and having special kernel
handling, but that's complicated by the fact that presumably you'd then
need to pick up the whole init thing in exit() rather than continuing it
in start_init().  In the meantime, Gordon has committed a change to always
link init statically.

> > A dynamicly linked /sbin/init just
> > makes it harder to get to the rescue bits, so it makes sense to
> > link init(8) staticly. Especially since there's no advantage to
> > dynamic linking init(8) that compensates for the inconvience.
> It obviously uses NSS.  How else could it be so bloated? :
> $ ls -l /sbin/init
> -r-x------  1 root  wheel  453348 Nov 18 10:30 /sbin/init
> (My version is linked statically of course.)
> The NSS parts of init might not be needed in normal operation, but its
> hard to tell. 

There appear to be at least two dependencies there, from my reading:

(1) getpwnam("root") so that we can check the root password when the
    console isn't marked as secure.

(2) Calls to setusercontext() to set up resources when running rc, also
    for uid 0, which results in libutil looking up the user to find the

I think that while home directory completion is useful for sh, it's safe
to have a working assumption of a local root user in the password file,
and that when prompting for a single user mode password, access to
directory services is probably going to fail anyway.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories

More information about the freebsd-current mailing list