zsh-static unsets $USERNAME:

xvii:~> zsh-static -f
xvii% echo $USERNAME

xvii%

Hi,

Vincent Lefevre wrote:

Yep, also in wheezy and squeeze.

		Regards, Axel

merge 769450 769448
kthxbye

Hi,

Vincent Lefevre wrote:

It actually seems to not set it. From Src/init.c:

    969     /* We cache the uid so we know when to *
    970      * recheck the info for `USERNAME'     */
    971     cached_uid = getuid();
    972
    973     /* Get password entry and set info for `USERNAME' */
    974 #ifdef USE_GETPWUID
    975     if ((pswd = getpwuid(cached_uid))) {
    976         if (EMULATION(EMULATE_ZSH))
    977             home = metafy(pswd->pw_dir, -1, META_DUP);
    978         cached_username = ztrdup(pswd->pw_name);
    979     }
    980     else
    981 #endif /* USE_GETPWUID */
    982     {
    983         if (EMULATION(EMULATE_ZSH))
    984             home = ztrdup("/");
    985         cached_username = ztrdup("");
    986     }

And USE_GETPWUID is not set in the static build. It's disabled in debian/rules:

   STATICFLAGS += --disable-dynamic-nss

This is probably the way how https://bugs.debian.org/207218 (changes
in libc cause zsh-static to immediately segfault) was fixed.

I wonder if #207218 would reappear nowadays, if we remove that line
above from debian/rules.

Removing that line definitely solves this issue, I just tried it.

Actually, removing that line also solves
https://bugs.debian.org/769448, so these two issues are actually the
same issue. The according code for this is probably in Src/glob.c:

   1469 #ifdef USE_GETGRNAM
   1470                             struct group *gr;
   1471                             sav = *tt;
   1472                             *tt = '\0';
   1473
   1474                             if ((gr = getgrnam(s + arglen)))
   1475                                 data = gr->gr_gid;
   1476                             else {
   1477                                 zerr("unknown group");
   1478                                 data = 0;
   1479                             }
   1480                             *tt = sav;
   1481 #else /* !USE_GETGRNAM */
   1482                             sav = *tt;
   1483                             zerr("unknown group");
   1484                             data = 0;
   1485 #endif /* !USE_GETGRNAM */

		Regards, Axel

On 2014-11-14 01:46:40 +0100, Axel Beckert wrote:
[...]

The ChangeLog says:

  Run dpkg-shlibdebs on /lib/libnss_files.so.* for zsh-static
  to help avoid segfaults due to continually-changing glibc NSS ABI.

But if the NSS ABI changes in an incompatible manner, the soname
should change, i.e. this was probably a bug in libc6.

Does this mean that zsh-static wouldn't really be a static build
because using the dynamic NSS library? Isn't it possible to use
the static library?

tag 354633 + confirmed
retitle 354633 zsh-static: %n in prompt expansion no longer set as root with 4.3.0-dev-5-1
retitle 354631 zsh-static: error in compaudit with 4.3.0-dev-5-1 as root
forcemerge 354631 354633 769448 769450
thanks

Hi,

Vincent Lefevre wrote:

Yep. That's how I got the idea to look at --disable-dynamic-nss.

Indeed. But see below, that's no bug in libc6 as the SONAME does
change.

Additionally, that mentioned dpkg-shlibdebs call is no more there. But
there's no other changelog entry which mentions dpkg-shlibdebs again.

Maybe this one from 4.3.0-dev-4-3 is the one where it got removed again:

  * For zsh-static, don't link against anything that requires NSS.

That's another question I wondered about, too. At least that's no more
the case:

→ ldd /bin/zsh-static
        not a dynamic executable

Even not with disabling that line:

→ ldd obj-static/Src/zsh
        not a dynamic executable

But then again I found https://bugs.debian.org/354631 and
https://bugs.debian.org/354633 already reported back in 2006. It's
currently blocked by https://bugs.debian.org/471208 (libncurses5:
ncurses+dietlibc) since Clint's plan seems to have been to use the NSS
routines from dietlibc for the static build. But I don't expect this
to happen anytime soon.

In #354631 is stated that the "compaudit:$linenumber: unknown group"
issue first shows up in compaudit:107: unknown group. Actually I think
it was already present in 4.3.0-dev-4-3 uploaded one day before,
because that's the one this changelog entry: "For zsh-static, don't
link against anything that requires NSS."

It also claims that this only happens as root. But at least on Wheezy
I also get it as normal user. But I suspect that only happens because
the reporter likely uses zsh-static as root, but only zsh as user. A
strong indication for this is at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354633#20

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354631#27 Clint
writes:

  [...] the problem is that user/group lookups are disabled in the
  -static build because glibc's NSS ABI is unstable and static
  binaries still need to load NSS modules dynamically.

  If we re-enable lookups, then zsh-static will segfault on any major
  libc upgrade. I don't know what the best solution here is.

That IMHO explains well why a statically complied binary still needs
dynamically linked libraries -- which may change their ABI _with_ an
SONAME bump, so no bug in libc6, but zsh-static should likely depend
on

  libc6 (>= $current_glibc_upstream_version), libc6 (<< $next_glibc_upstream_version)

if we remove "STATICFLAGS += --disable-dynamic-nss" from debian/rules.

So I'm no more sure if removing that line is really a good idea.

OTOH: We are thinking about dropping the zsh-static package after
Jessie anyways. Popcon's "vote" is around 25 and such issues don't
seem to have bothered people too much since 2006.

So if anyone wants to keep zsh-static and is reading this, please
_tell_ us!

		Regards, Axel

Hi,

Isn't it possible to get this NSS code in the static binary instead
of having to load modules dynamically?

So, if the libc6 version is incorrect, the module cannot be found
because of the SONAME bump. So, one should get a clean error with
a meaningful error message instead of a segfault in such a case.

IMHO there are two better solutions, but this would need some change
in the glibc packaging:

1. The dynamic modules are provided by a separate package, whose name
depends on the ABI (which is typically done for usual libraries, where
different versions are co-installable). The advantage is that libc6
and zsh-static upgrades could be done independently for the user (very
useful in case of blocking bugs).

2. If this is not possible, glibc could provide a virtual package
associated with the ABI, so that zsh-static could directly depend
on the ABI itself.

Removing zsh-static would be better than keeping a buggy one,
in particular one that isn't really static.

Hi,

Vincent Lefevre wrote:

Well, the current state is _static_, but castrated so that some
features are missing (to ensure that staticness). I don't see it as a
bug in zsh or in the packaging specifically, more as a necessary
annoyance which may get new chances to be fixed over time.

		Regards, Axel