Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: usernames are not resolving correctly for users not listed in /etc/passwd #863

Closed
morgan-greywolf opened this issue Feb 28, 2024 · 5 comments
Labels
duplicate This issue or pull request already exists errors Something isn't working

Comments

@morgan-greywolf
Copy link

morgan-greywolf commented Feb 28, 2024

Usernames are not being resolved if the user is not coming from /etc/passwd

  • eza v0.18.4 [+git]
  • command-line eza --long --header --icons
  • Oracle Linux 8.9 with Red Hat compatibility kernel 4.18.0-477.13.1 on x86_64

Example:

$ eza --long --header --icons ~/rpmbuild
Permissions Size User    Date Modified Name
drwxr-xr-x@    - 8126474  6 Dec  2023   BUILD
drwxr-xr-x@    - 8126474  6 Dec  2023   BUILDROOT
drwxr-xr-x@    - 8126474 21 Jul  2023   RPMS
drwxr-xr-x@    - 8126474 15 Feb 16:56   SOURCES
drwxr-xr-x@    - 8126474 15 Feb 16:56   SPECS
drwxr-xr-x@    - 8126474 21 Jul  2023   SRPMS

8126474 should in this case resolve to my username:

getent passwd 8126474
rshinn:*:8126474:100:Rob Shinn:/home/users/rshinn:

In this case, getent is resolving my user ID via the system libc function getpwuid(3). I suspect the problem is actually with the uzers-rs Rust library rather than your code, but I'm not yet sufficiently proficient in Rust to make that determination. That project claims to be a wrapper around the same libc library functions, so users.get_user_by_uid should be a wrapper around getpwuid(3)/getpwuid_r(3) but obviously something is broken somewhere.

This is what I imagine the code in the library should be doing (in C and shamelessly ripped and rewritten from the manpage):

#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
  

int
main(int argc, char *argv[])
{
    struct passwd pwd;
    struct passwd *result;
    char *buf;
    size_t bufsize;
    int s;
    uid_t uid;

    if (argc != 2) {
        fprintf(stderr, "Usage: %s uid\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    bufsize = sysconf(_SC_GETPW_R_SIZE_MAX);
    if (bufsize == -1)          /* Value was indeterminate */
        bufsize = 16384;        /* Should be more than enough */

    buf = malloc(bufsize);
    if (buf == NULL) {       
        perror("malloc");
        exit(EXIT_FAILURE);
    }                 
    uid = atoi(argv[1]);
    s = getpwuid_r(uid, &pwd, buf, bufsize, &result);
    if (result == NULL) {
        if (s == 0)   
            printf("Not found\n");
        else {        
            errno = s;
            perror("getpwnam_r");
        }             
        exit(EXIT_FAILURE);
    }                 
                      
    printf("Name: %s; UID: %ld\n", pwd.pw_name, (long) pwd.pw_uid);
    exit(EXIT_SUCCESS);
}                            

The above code works on the same system:

$ gcc getpwuid.c -o getpwuid
$ ./getpwuid 8126474
Name: rshinn; UID: 8126474
@morgan-greywolf morgan-greywolf added the errors Something isn't working label Feb 28, 2024
@morgan-greywolf
Copy link
Author

Update: Looking at line 342 in src/base.rs does suggest that users.get_user_by_uid() is a wrapper around getpwuid_r(), which is obviously just a Rust binding for the C function. Again, I'm not really proficient in Rust, but maybe someone with more skill in Rust could look at this.

@MartinFillon
Copy link
Contributor

@gierens do you think this and #616 could be linked ?

@gierens
Copy link
Member

gierens commented Mar 20, 2024

@MartinFillon Sorry for the late reply, yes I think it is.

@morgan-greywolf Someone traced this back to uzers and opened an issue there. I'll take a look at it later the day or tomorrow.

@MartinFillon
Copy link
Contributor

@MartinFillon Sorry for the late reply, yes I think it is.

its okay we all have lifes

@gierens gierens added the duplicate This issue or pull request already exists label Mar 21, 2024
@gierens
Copy link
Member

gierens commented Mar 21, 2024

I looked into this and the short answer is MUSL does not support sideloading the NSS plugins needed to retrieve things from SSSD.

Also, this is a duplicate of #541 therefore I'm going to close this one so we keep the discussion contained in the original issue. There I'm also going to go into more details about the uzers dependency.

@gierens gierens closed this as completed Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists errors Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants