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

INITGROUPS fails on GIDs > 2147483647 #72

Open
max-privatevoid opened this issue Oct 30, 2023 · 3 comments
Open

INITGROUPS fails on GIDs > 2147483647 #72

max-privatevoid opened this issue Oct 30, 2023 · 3 comments

Comments

@max-privatevoid
Copy link

Originally reported in a fork.

User max is member of a group with GID 2709991565.
Running id max, nsncd (unstable-2022-11-14 from nixpkgs 96f8f4a038a190f7511da79ef7e77bec5e4b811a) returns:

uid=646000001(max) gid=646000001(max) groups=646000001

nscd returns:

uid=646000001(max) gid=646000001(max) groups=646000001(max),2709991565(infra_admins)

Log for nsncd shows this error message:

Jun 11 00:00:39.334 ERRO error handling request, err: out of range integral type conversion attempted, request_type: INITGROUPS, thread: worker_5

Users with GIDs <= 2147483647 get their groups listed correctly, so I'm guessing this is a signed vs. unsigned issue.

@leifwalsh
Copy link
Collaborator

This might be a long shot but do you have a reasonable way to reproduce this in a test? I'm not really sure how to construct this scenario in a lab-like environment in order for us to figure out what's going on, but maybe you know how groups work better than I do?

@max-privatevoid
Copy link
Author

You can reproduce it by creating a local group with a GID of 2147483648 and adding a user to that group, then running id on that user. nsncd always prints the error, but it looks like glibc has a fallback mechanism in which it'll read /etc/group by itself in case it doesn't get a response from the daemon. To prevent this and actually see the client be affected by the bug, you can use bwrap to hide /etc/group from the client process:

bwrap --bind / / --bind /dev/null /etc/group id theuser

I've written a small NixOS test for this in https://github.com/max-privatevoid/nsncd-bug-72.

I also made a simple patch that just replaces an i32 with a u32 in the serialize_initgroups function.

The NixOS test runs two VMs, with an unpatched and a patched version of nsncd respectively, and performs the test with id described above, proving that the patch fixes the issue at least in this particular scenario. I assume there are probably more places in the code where i32 is used but u32 would be the correct type.

$ nix build github:max-privatevoid/nsncd-bug-72 -L

I've also exposed the interactive mode of the test for convenience. This allows for direct interaction with the VMs for further inspection.

$ nix run github:max-privatevoid/nsncd-bug-72#interactive
>>> start_all()

@morisja
Copy link
Collaborator

morisja commented Oct 20, 2024

I've submitted a PR and updated tests for this case, @max-privatevoid would you please take a quick look
#140

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

3 participants