Debian currently skips building the libnss-db library from the glibc codebase. Instead, it provides a separate libnss-db package based on an older standalone codebase. That standalone codebase was split out of glibc around 2012, when Oracle acquired BerkeleyDB and glibc moved its nss-db backend to a BerkeleyDB-free implementation with an incompatible on-disk format. The Debian libnss-db package is therefore based on an old, now largely unmaintained implementation, which has a number of bugs. In particular: - it performs poorly during enumeration because of redundant openat() calls; - it can occasionally cause initgroups() to set incorrect group membership at login, because getgrouplist() is not thread-safe. I can provide reproducers for those bugs if useful, but those are separate issues; I mention them here only as context and motivation for this request. The glibc implementation is of better quality and would be a worthwhile alternative. I am preparing an MR in Salsa to make a new libc6-libnss-db package as part of glibc to address this issue. This package is functionally identical to the current libnss-db package and can replace it, although both packages cannot be installed at the same time.
Hi Yan, One of the main reason to use the separate libnss-db package based on BerkeleyDB is that the file format is architecture independent. At that time, it was not the case of the glibc implementation. Do you know if it is still the case? This is important in the multilib and multiarch context. That said as db5.3 is scheduled for removal from the archive, I understand that you are investigating alternatives. One of them is libnss-cache, although the file format is quite different. I have added a few comment to your MR. This doesn't mean it will get accepted once fixed, we need to understand the limitation of the glibc version first. Regards Aurelien
Hi Aurelien, thank you for taking the time to look at this issue and the MR. Indeed, the glibc implementation is still neither multilib nor multiarch capable. It does no byte-order handling, *and* also has issues with hash key generation (it uses a unsigned long as part of hash key generation). That said, isn't there value in packaging the upstream glibc libnss_db.so, as an optional package, to provide a migration path for `libnss-db` users that have no multilib/mutiarch needs without forcing them to a completely different solution (libnss-cache or other) ? I'm certainly in need of a such a path, and perhaps many of the current users are. It would be nice to provide at least a partial solution. The original intent of libnss-db backend is purely as a performance enhancement on top of the local files backend. As such, in multilib environments, I think the worst case is a loss of performance in the non-native case(s), which is arguably better than losing performance in *all* cases. If `nsswitch.conf` database entries include the db backend, and the `libnss_db.so` isn't available for the correct arch, it will simply skip the backend. I will attend to those, and try to address them in further commits.
Hi Yan, This is assuming that libnss-db is only used as a caching solution, and thus the fallback to /etc/passwd and /etc/group is acceptable. However there are other usages and the current libnss-db package even provides the /etc/default/libnss-db to configure that. Regards Aurelien