Post B7Yph10r1beo8OD1gu by mupuf@social.treehouse.systems
(DIR) More posts by mupuf@social.treehouse.systems
(DIR) Post #B7Wxf2tZSuzGi8SEPQ by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov what is the context of this? do you know what problem they're trying to solve?EDIT: nvm the quote wasn't showing the whole post
(DIR) Post #B7XM8EPC9F3nhrhChE by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov Hmm ok so apparently they're trying to use newer APIs (like pidfd_spawn) where available, and otherwise fall back to older ones.I think any of those functions getting a new symbol version would screw them over:- For dlsym or any of the fallbacks, it would build with the new symbol version and not run on an older system. However, they claim to force older symbols at build time whenever they see this happens:https://mastodon.social/@daandemeyer/1167831463832081811/
(DIR) Post #B7XMUJ5hPLtwbq6SsC by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov - For the newer symbols they look up with dlsym, there's effectively no symbol versioning, right? So if such a function takes a struct as an argument, and the exact memory layout of the struct differs between the build machine and the host machine, they'll call it with nonsensical arguments and get unpredictable behaviour?
(DIR) Post #B7YA88sFi0cCG9RECe by amonakov@mastodon.gamedev.place
0 likes, 0 repeats
@wolf480pl yes; even without a struct involved, if the new version has a different ABI for any other matter, it will blow up
(DIR) Post #B7YANcjEzZp1CCbaRE by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov sounds like a reckless thing to do for the most important daemon in the system...
(DIR) Post #B7YBiNV8u0IM0KTHKC by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov I was gonna say "at this point they'd be better off vendoring glibc, since the kernel's syscall ABI is backwards-compatible"except of course they can't, because of nsswitch...I'm getting more and more convinced that we need a language-agnostic nsswitch replacement.
(DIR) Post #B7YBkjDT8auNvnKE2y by wolf480pl@mstdn.io
0 likes, 0 repeats
@amonakov (and by language agnostic I mean in its own process)
(DIR) Post #B7Yph10r1beo8OD1gu by mupuf@social.treehouse.systems
0 likes, 0 repeats
@wolf480pl @amonakov I guess it is the responsibility of the package managers to rebuild systemd when any of its dependency (optional or not) gets updated...Not much different from usual then.
(DIR) Post #B7Yph1Go4IPwvrflYW by wolf480pl@mstdn.io
0 likes, 0 repeats
@mupuf @amonakov Yeah but with symbol versioning, you'd have a safety net in case the packager makes a mistake, or an admin does a partial upgrade (which every admin knows shouldn't be done).Also, if you have to rebuild systemd with the same version of libc as the one with which it's gonna run, that kinda defeats the whole reason why systemd does all this dance with shims and dlsyms, doesn't it?
(DIR) Post #B7Yppre9DYhTgwo91E by wolf480pl@mstdn.io
0 likes, 0 repeats
@mupuf @amonakov (re whole reason:the systemd dev behind that feature said:> The goal is to make systemd run everywhere regardless of where it was built.)
(DIR) Post #B7YqxQm56wkucWgsgC by novenary@akko.wtf
0 likes, 0 repeats
@wolf480pl @amonakov nixos "solves" this problem by moving nss out of process with nscd (or really: https://github.com/twosigma/nsncd)this allows loading arbitrary nss modules system-wide for packages built against multiple glibc versions and architectures (ie 32 bit)
(DIR) Post #B7YqxR0cEuNjLbUUKm by wolf480pl@mstdn.io
0 likes, 0 repeats
@novenary @amonakov Interesting.But I heard nscd protocol does not support listing (eg. like `getent passwd` will list all users) - is that true?
(DIR) Post #B7Ys6XKuBTlfX0svwW by wolf480pl@mstdn.io
0 likes, 0 repeats
@novenary @amonakov btw. skarnet (of s6 fame) has their own protocol of course:https://skarnet.org/software/nsss/as does systemdhttps://systemd.io/USER_GROUP_API/