I am on an Ubuntu system where my Linux user is managed by LDAP. I am using nix as a package manager in single-user mode.
Here is a simple C program to test the functionality of getpwuid
:
#include <pwd.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char* argv[]) {
uid_t uid = getuid();
printf("%d\n", uid);
struct passwd* pwuid = getpwuid(uid);
if (pwuid == NULL) {
printf("struct is null!\n");
return 1;
}
printf("%s\n", pwuid->pw_name);
return 0;
}
If I compile this in my normal shell and run it, I get the following output:
170636273
brasswood
ldd
output:
linux-vdso.so.1 (0x00007ffe6dbf8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000733c62200000)
/lib64/ld-linux-x86-64.so.2 (0x0000733c6260f000)
If I nix-shell -p gcc
and recompile the same file, I get the following output:
170636273
struct is null!
ldd
output:
linux-vdso.so.1 (0x00007fff8010f000)
libc.so.6 => /nix/store/maxa3xhmxggrc5v2vc0c3pjb79hjlkp9-glibc-2.40-66/lib/libc.so.6 (0x00007ed582407000)
/nix/store/maxa3xhmxggrc5v2vc0c3pjb79hjlkp9-glibc-2.40-66/lib/ld-linux-x86-64.so.2 => /nix/store/maxa3xhmxggrc5v2vc0c3pjb79hjlkp9-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007ed582601000)
In summary, linking against my Ubuntu system’s libc
works fine, while linking against the nix store’s libc
breaks the functionality of getpwuid()
. Why is this happening?
You cant mix and match glibc versions like this im afraid. The nss module of ldap gets loaded into the memory of nix’s glibc but they might not be abi compatible due to being built against different versions of glibc.
In nixos we work around this by piping all name requests through nscd which then loads the nss modules. So that we have a stable API interface for name lookups
In other distros we don’t have that luxury. You’re basically out of luck if your glibc version in Nixpkgs doesn’t match your distros. Expect undefined behaviour and segfaults.
See
NixOS:master
← flokli:remove-nscd
opened 07:34PM - 16 Sep 21 UTC
###### Motivation for this change
Using nscd leaks DNS traffic across namespace… s, [causes friction](https://github.com/NixOS/nixpkgs/issues/95107) in general.
Fixes: https://github.com/NixOS/nixpkgs/issues/135888
Fixes: https://github.com/NixOS/nixpkgs/issues/105353
Cc: https://github.com/NixOS/nixpkgs/issues/52411#issuecomment-757347201
This was long suggested in https://github.com/NixOS/nixpkgs/issues/55276.
I ran the avahi tests.
See the commit message(s) and release notes for details.
###### Things done
- Built on platform(s)
- [x] x86_64-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- [ ] For non-Linux: Is `sandbox = true` set in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/#sec-conf-file))
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
- [21.11 Release Notes (or backporting 21.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2111-release-notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
cc @zhenyavinogradov @3nprob
For context
And
NixOS:staging
← tweag:nss-path
opened 07:35PM - 29 Jan 21 UTC
With this, you can set `$NIX_GLIBC_NSS_PATH` to a colon-separated list of direct… ories in which glibc will look for NSS modules. In environments where nscd cannot be used, this allows dealing with non-standard NSS modules in a less sledgehammer-y way than setting `$LD_LIBRARY_PATH` (which affects everything, and in particular could cause ABI incompatibilities).
The default value is
`/nix/run/glibc-nss-path/${out-hash}:/nix/run/glibc-nss-path`
where `out-hash` is the hash part of `glibc.out` (e.g. `/nix/run/glibc-nss-path/0cjq75a1cgwd7ccxsp9warzjax1kr7ag`). Thus,
`glibc` will look for an NSS module named `libnss_mymachines.so.2` at
`/nix/run/glibc-nss-path/0cjq75a1cgwd7ccxsp9warzjax1kr7ag/libnss_mymachines.so.2`
and
`/nix/run/glibc-nss-path/libnss_mymachines.so.2`
These are tried *after* the default search locations (i.e. `$LD_LIBRARY_PATH` and `glibc.out/lib`) so they don't override any current behaviour.
The use of `/nix/run` rather than `/run` is because the user may have write access to `/nix` but not to `/run`. On NixOS, it's intended than `/nix/run` is a symlink / bind-mount to `/run`.
<!--
To help with the large amounts of pull requests, we would appreciate your
reviews of other pull requests, especially simple package updates. Just leave a
comment describing what you have tested in the relevant package/service.
Reviewing helps to reduce the average time-to-merge for everyone.
Thanks a lot if you do!
List of open PRs: https://github.com/NixOS/nixpkgs/pulls
Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
-->
###### Motivation for this change
This does for NSS modules what `/run/opengl-driver` does for our OpenGL support. In particular it's intended for non-NixOS, non-nscd environments that require non-standard NSS modules.
Maybe instead of `NIX_GLIBC_NSS_PATH` we could use a generic environment variable as suggested in https://gist.github.com/Infinisil/3366e7dfc9a01f6eeb25b5cb475cc585 (and then look for `out-hash/nss` and `nss` relative to the directories in that variable).
###### Things done
- [x] Tested using sandboxing ([nix.useSandbox](https://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](https://nixos.org/nix/manual/#sec-conf-file) on non-NixOS linux)
- Built on platform(s)
- [x] NixOS
- [ ] macOS
- [ ] other Linux distributions
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
- [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
- [ ] Ensured that relevant documentation is up to date
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
For a possible solution
1 Like
Ok, let me check if I understand the problem correctly.
The call to getpwuid
resolves to the function in the nix store glibc
.
That glibc
then looks in /etc/nsswitch.conf
to find out how to query the passwd entry.
/etc/nsswitch.conf
directs glibc
to, for example, run a subroutine defined in /usr/lib/x86_64-linux-gnu/libnss_sss.so.2
.
glibc
then dlopen
s this file and tries to call the subroutine.
But the problem is, /usr/lib/x86_64-linux-gnu/libnss_sss.so.2
was written for my distro’s glibc
and presents a different ABI than what nix’s glibc
is expecting. Segfault. Is this correct?
Would simply running nsncd
on the host system solve the problem? Specifically, a version of nsncd
that was built against the same version of glibc
that is running on the host system?
flokli
April 10, 2025, 5:02am
4
Yes, that’s a valid fix for this, and why we worked on getting everything into nsncd upstream.
1 Like
Follow-up question: Why not automatically install and run nsncd as part of the installation process for nix as a package manager on top of another distro?
flokli
April 21, 2025, 7:17pm
6
I think one of the main reasons is that it’s complicated. Everything that interacts with the existing distro might look slightly different on different distros. It should probably at least be documented more prominently.