Effectiveness of --disable-dynamic-nss?

Effectiveness of --disable-dynamic-nss?

[Mikael Magnusson]

Hi,

Someone was mentioning on the #zsh channel that $USERNAME was empty
when they compiled statically and I vaguely remembered glibc doesn't
support name lookup statically, which led me to look at
--disable-dynamic-nss. I noticed it seems to define USE_* stuff when
the switch is not given for some HAVE_* stuff that pertains to name
lookup. However, even in the commit where it was introduced, it
skipped many HAVE_GETPWNAM (for example), and converted others, some
even within the diff context of other defines that were changed. So my
two questions are:

Is there a reason they were left alone or does the switch not work?
If they're all meant to be disabled, why not just have it #undef the
HAVE_* defines instead of defining new things and changing every user,
and hope nobody ever introduces new HAVE_* #ifdefs?

And tangentially, is $USERNAME supposed to return anything when
compiled with this switch given? The function that handles this
parameter was switched to USE_INITGROUPS but still uses HAVE_GETPWNAM,
which is confusing to me.

-- 
Mikael Magnusson

Re: Effectiveness of --disable-dynamic-nss?

[Peter Stephenson]

On Thu, 06 Nov 2014 15:11:59 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> Someone was mentioning on the #zsh channel that $USERNAME was empty
> when they compiled statically and I vaguely remembered glibc doesn't
> support name lookup statically, which led me to look at
> --disable-dynamic-nss. I noticed it seems to define USE_* stuff when
> the switch is not given for some HAVE_* stuff that pertains to name
> lookup. However, even in the commit where it was introduced, it
> skipped many HAVE_GETPWNAM (for example), and converted others, some
> even within the diff context of other defines that were changed. So my
> two questions are:
> 
> Is there a reason they were left alone or does the switch not work?
> If they're all meant to be disabled, why not just have it #undef the
> HAVE_* defines instead of defining new things and changing every user,
> and hope nobody ever introduces new HAVE_* #ifdefs?
> 
> And tangentially, is $USERNAME supposed to return anything when
> compiled with this switch given? The function that handles this
> parameter was switched to USE_INITGROUPS but still uses HAVE_GETPWNAM,
> which is confusing to me.

I haven't looked at the history, but from your report this looks like a
case of fairly severe code rot combined with a partial implementation.
I don't think anybody round here is likely to have verified that option
even for basic operation for quite a while.

pws

Re: Effectiveness of --disable-dynamic-nss?

[Bart Schaefer]

On Nov 6,  3:11pm, Mikael Magnusson wrote:
} 
} Someone was mentioning on the #zsh channel that $USERNAME was empty
} when they compiled statically and I vaguely remembered glibc doesn't
} support name lookup statically

I build a fully-static zsh all the time and have never had a problem
with USERNAME not being set.  Is this platform-specific, or is the
"when they compiled statically" specific to dynamic-nss ?

} Is there a reason they were left alone or does the switch not work?
} If they're all meant to be disabled, why not just have it #undef the
} HAVE_* defines instead of defining new things and changing every user,
} and hope nobody ever introduces new HAVE_* #ifdefs?

I think the idea here is that multiple lookup methods may be compiled
in, and you can choose to use different subsets of them, so it may be
the case that HAVE_* is true while desiring to prefer some other way
if available vs. never use some other method even if it is available.

I can imagine this logic got confused somewhere along the way, or that
certain cases were missed.  I think Clint Adams still reads this list
and it looks like --disable-dynamic-nss was his patch, so maybe he can
speak to it more directly.

Re: Effectiveness of --disable-dynamic-nss?

[Mikael Magnusson]

On Thu, Nov 6, 2014 at 5:17 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 6,  3:11pm, Mikael Magnusson wrote:
> }
> } Someone was mentioning on the #zsh channel that $USERNAME was empty
> } when they compiled statically and I vaguely remembered glibc doesn't
> } support name lookup statically
>
> I build a fully-static zsh all the time and have never had a problem
> with USERNAME not being set.  Is this platform-specific, or is the
> "when they compiled statically" specific to dynamic-nss ?

Well, they said they tried on both debian and gentoo, and that it
seemed disable-dynamic-nss was used on the debian build but not in the
gentoo build. I'm not sure if that's 100% trustworthy though. The
gentoo ebuild specifies only --disable-dynamic but also adds -static
to ldflags manually. They found this semi-old gentoo bugzilla entry
about it as well, https://bugs.gentoo.org/show_bug.cgi?id=412301 but
it's not very informative.

[I tried to test this locally, but I don't have a static ncurses
installed, which causes the test for boolcodes to return negative
failing to link, which in turn causes a double declaration compilation
failure.]

-- 
Mikael Magnusson

Re: Effectiveness of --disable-dynamic-nss?

[Clint Adams]

On Thu, Nov 06, 2014 at 08:17:01AM -0800, Bart Schaefer wrote:
> I can imagine this logic got confused somewhere along the way, or that
> certain cases were missed.  I think Clint Adams still reads this list
> and it looks like --disable-dynamic-nss was his patch, so maybe he can
> speak to it more directly.

These days I tend not to unless my attention is called to something,
but here's what I remember.

The switch was intended for the zsh-static package in Debian, because
despite static compilation, (e)glibc uses dynamically-loaded NSS
modules.  These modules break ABI fairly often, and this makes less
useful a statically-compiled rescue shell.

I vaguely remember things being suboptimal and deciding that it would
be better to link zsh-static with dietlibc and avoid the problem
entirely, but this was blocked by the lack of a dietlibc-linked
ncurses.

I have no recollection of any of the implementation particularities.

These days static shells and utilities seem relatively unimportant,
especially when Debian has things like the grml-rescueboot package.