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

Unable to get sss usernames with musl build #20

Open
raffitz opened this issue Mar 12, 2024 · 2 comments
Open

Unable to get sss usernames with musl build #20

raffitz opened this issue Mar 12, 2024 · 2 comments

Comments

@raffitz
Copy link

raffitz commented Mar 12, 2024

Builds targeting musl are unable to fetch usernames of users not in /etc/passwd.

use uzers::{get_user_by_uid, get_current_uid};

fn main() {
    let uid = get_current_uid();
    println!("Current UID: {}", uid);
    if let Some(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

This has impact in other tools that depend on uzers, like eza: eza-community/eza#541 and eza-community/eza#616 .

@gierens
Copy link
Member

gierens commented Mar 15, 2024

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.

@gierens
Copy link
Member

gierens commented Mar 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants