You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Builds targeting musl are unable to fetch usernames of users not in /etc/passwd.
use uzers::{get_user_by_uid, get_current_uid};fnmain(){let uid = get_current_uid();println!("Current UID: {}", uid);ifletSome(user) = get_user_by_uid(uid){println!("User: {:?}", user);}else{println!("Failed to get user by UID");}}
This gets the following output in a CentOS 7.3 machine:
$ cargo run --release
Current UID: 10058586
User: User(10058586, grafael)
$ cargo run --release --target=x86_64-unknown-linux-musl
Current UID: 10058586
Failed to get user by UID
Thanks for bringing this to my attention @raffitz ... I was aware of those eza issues but never found the time to setup PAM to try and reproduce or debug it. ... With your minimal example for reproducing it here, I guess I can give this another shot and try to debug this in the next few days.
Alright, good news first: I finally found a machine where I can test this without having to setup SSSD myself and I can confirm the dynamic GLIBC build works fine, but the static MUSL build fails to fetch the user.
Now the bad news: I poked around a bit and believe the problem is that MUSL does not support sideloading the NSS plugins needed to retrieve things from SSSD like GLIBC does and thus does only ever read users from /etc/passwd, see: SSSD/sssd#6586
This leaves two options in my opinion, either we would have to put the SSS support into uzers which seems like a real hassle or downstream applications would have to avoid MUSL builds.
Builds targeting musl are unable to fetch usernames of users not in
/etc/passwd
.This gets the following output in a CentOS 7.3 machine:
This has impact in other tools that depend on uzers, like eza: eza-community/eza#541 and eza-community/eza#616 .
The text was updated successfully, but these errors were encountered: