bug: User and group names not displayed with MUSL build

[mathomp4]

Boilerplate:

$ eza --version
eza - A modern, maintained replacement for ls
v0.14.2 [+git]
https://github.com/eza-community/eza

and the OS is SLES 15SP4.

I am seeing an issue with eza that I also see in lsd (see https://github.com/lsd-rs/lsd/issues/374) and I saw in the past. I'm not a rust expert, but I'm guessing some underlying crate is the issue? 🤷🏼

To wit, if I use plain ls:

$ /bin/ls -l
total 10544
-rwxr-xr-x 1 mathomp4 g0620 1716360 Oct 12 04:09 eza-gnu
-rwxr-xr-x 1 mathomp4 g0620 1904840 Oct 12 04:10 eza-musl
-rw-r--r-- 1 mathomp4 g0620  799287 Oct 12 04:12 eza_x86_64-unknown-linux-gnu.tar.gz
-rw-r--r-- 1 mathomp4 g0620  964957 Oct 12 04:12 eza_x86_64-unknown-linux-musl.tar.gz

I see mathomp4 and g0620 as I'd expect. Now if I use a GNU eza:

$ ./eza-gnu -lg
.rwxr-xr-x 1.7M mathomp4 g0620 12 Oct 04:09 eza-gnu
.rwxr-xr-x 1.9M mathomp4 g0620 12 Oct 04:10 eza-musl
.rw-r--r-- 799k mathomp4 g0620 12 Oct 04:12 eza_x86_64-unknown-linux-gnu.tar.gz
.rw-r--r-- 965k mathomp4 g0620 12 Oct 04:12 eza_x86_64-unknown-linux-musl.tar.gz

Okay. Now MUSL eza:

$ ./eza-musl -lg
.rwxr-xr-x 1.7M 31128555 20620 12 Oct 04:09 eza-gnu
.rwxr-xr-x 1.9M 31128555 20620 12 Oct 04:10 eza-musl
.rw-r--r-- 799k 31128555 20620 12 Oct 04:12 eza_x86_64-unknown-linux-gnu.tar.gz
.rw-r--r-- 965k 31128555 20620 12 Oct 04:12 eza_x86_64-unknown-linux-musl.tar.gz

MUSL eza is showing the numeric UID and GID, but not the "human-readable" version. Now, it's possible GNU has the wrong behavior (maybe I'm missing flags?) but in any case, the GNU and MUSL builds have different behavior.

[Freaky]

eza's using uzers, a derivative of users which is what exa was using. Doesn't look like it's changed much since I last poked at it.

It's just calling getpwuid_r - there shouldn't be that much for it to break. Do you have any other (non-Rust) musl binaries that can map uids? Have you tried running the binary under strace to see what it's actually doing?

I note you have rather high user and group ids - are they identified by anything more complex than just /etc/passwd?

[mathomp4]

@Freaky I'm...not sure. It's on a NASA supercomputer cluster, so it's possible things are more complex. Indeed, if I look, my name is not in /etc/passwd.

But, I used the power of ChatGPT to make a C code that uses getpwuid_r (I am a Fortran programmer so even simple C code like this is hard for me 😄):

#include <stdio.h>
#include <stdlib.h>
#include <pwd.h>
#include <string.h>

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <UID>\n", argv[0]);
        return 1;
    }

    // Convert the user input (UID) to an integer
    uid_t uid = atoi(argv[1]);

    struct passwd pwd;
    struct passwd *result;
    char buffer[1024]; // A buffer to store the user information

    // Call getpwuid_r to retrieve the user information
    if (getpwuid_r(uid, &pwd, buffer, sizeof(buffer), &result) == 0) {
        if (result != NULL) {
            printf("User Information:\n");
            printf("Username: %s\n", pwd.pw_name);
            printf("User ID: %d\n", pwd.pw_uid);
            printf("Group ID: %d\n", pwd.pw_gid);
            printf("Home directory: %s\n", pwd.pw_dir);
            printf("Shell: %s\n", pwd.pw_shell);
        } else {
            fprintf(stderr, "User with UID %d not found.\n", uid);
            return 1;
        }
    } else {
        perror("getpwuid_r");
        return 1;
    }

    return 0;
}

and when I run it:

$ gcc test.c
$ ./a.out 31128555
User Information:
Username: mathomp4
User ID: 31128555
Group ID: 20620
Home directory: /home/mathomp4
Shell: /usr/local/bin/bash

So, it looks like getpwuid_r is doing its thing.

[mathomp4]

Also, I asked ChatGPT about getting the group name, it added a call to getgrgid and that test code shows the right group.

[Freaky]

gcc test.c is probably giving you a glibc build - can you try with musl-gcc -static?

[ariasuni]

I’ve seen that maybe you need the musl to also be installed for that to work, could you try installing it on your computer and see if it works?

[mathomp4]

I'll try it out next week when I'm on the cluster again. Never tried building musl so it might take me a few tries.

[j-xella]

Is there any progress with this issue?

Alternatively, is it possible to add CentOS build to the list of artefacts, something that would use glibc and run on older versions of linux?

[mathomp4]

I'd forgotten all about this as my job got...busy. I was never able to build/install musl-gcc back then but maybe I can now? Does anyone have a primer on how to build that?

[mathomp4]

That said, can still confirm I see this with eza musl v0.17.1

[simaoafonso-pwt]

https://github.com/eza-community/eza/issues/616#issuecomment-1964004518

I think mixing musl and glibc with PAM does not work. If the system PAM binaries and eza use the same "type", it should work.

I don't have a musl system with PAM to test this hypothesis, does anyone use Alpine Linux and PAM with sss?

@j-xella is right, if the binaries were build on an older glibc, they could work on CentOS 7, which is still supported for a couple months. It's easy to build your own version, just install https://rustup.rs, get a release tarball and run cargo build --release, the binaries will be in target/release.

[gierens]

I poked around a bit in context of rustadopt/uzers-rs#20 and can confirm that a MUSL build of uzers fails to retrieve SSS usernames.

The core of the matter seems to be that retrieving information from SSSD requires NSS plugins which GLIBC sideloads after consulting /etc/nssswitch.conf. MUSL however does not support NSS, see: https://github.com/SSSD/sssd/issues/6586 or citing from the MUSL wiki: "musl does not have (or want) NSS.", see https://wiki.musl-libc.org/future-ideas.html.

As I said in the uzers issue I see two options, either building the SSS support into uzers which doesn't seem like a feasible thing, though, or avoiding MUSL builds when SSS is a requirement.

[j-xella]

Very often, the reason users have to use MUSL build is because they are stuck with old versions of Linux, where installed glibc is too old for the glibc version of eza. For those users, another solution could be an eza build for centOS. My understanding is those builds use older version of glibc.

Is it very difficult to add CentOS artefact to the list of artefacts produced for every eza release? Wezterm does something similar.

[cafkafk]

Very often, the reason users have to use MUSL build is because they are stuck with old versions of Linux, where installed glibc is too old for the glibc version of eza. For those users, another solution could be an eza build for centOS. My understanding is those builds use older version of glibc.

Is it very difficult to add CentOS artefact to the list of artefacts produced for every eza release? Wezterm does something similar.

How hard is it to produce them? If we can automate it for free somehow that's great, if someone wants to try and figure out some solution, that's welcome. It should just seek to avoid creating more work for maintainers.