Hi Aurelien, and others,
I'm writing regarding the libnss-db patch proposed in Debian bug #1101371
[1],
which I've also been working on landing in Ubuntu (LP: #2121543 [2]).
I wanted to check whether you'd be willing to review and accept this patch
into the Debian package.
libnss-db currently closes and re-opens the Berkeley DB file for each entry
during iteration (e.g., `getent passwd`). This is controlled by the
`stayopen`
parameter in db-XXX.c, which is always passed as 0 by glibc, effectively
forcing close/reopen on every entry.
For small DB files this is not noticeable, but in environments with large DB
files (e.g., 20,000+ entries), this results in approximately 40x worse
performance compared to keeping the file open.
The Proposed patch is simple, in src/db-XXX.c, change:
keep_db |= stayopen;
to:
keep_db = 1;
This ignores the stayopen parameter and forces the DB file to remain open
during iteration, matching the behavior adopted by glibc itself. Proposed
in [1].
This change aligns libnss-db with how glibc's own NSS modules have handled
stayopen since 2016:
- glibc's nss_files/files-XXX.c ignores stayopen (since CVE-2014-8121 fix)
- glibc's nss_db/db-XXX.c already uses `keep_db |= 1` (always stays open)
- nss-pam-ldap similarly ignores stayopen
I submitted this upstream to glibc as well [3][4], but after closer
investigation, I concluded that glibc's nss_db implementation has diverged
significantly from libnss-db and does NOT have this problem; glibc's nss_db
already mmap's the file and tracks the open state correctly, only opening if
state.header is NULL. The issue is specific to the libnss-db Debian package,
which uses a different Berkeley DB-based implementation.
CVE-2014-8121: As noted by the original bug reporter (François Lesueur),
the stayopen
behavior is historically linked to CVE-2014-8121 [5]. However, this patch
does NOT
reintroduce that vulnerability:
- CVE-2014-8121 affected glibc's nss_files (flat text-file NSS module),
not nss_db or libnss-db (Berkeley DB-based).
- The CVE was caused by file pointer (FILE*) resets during concurrent
lookup + iteration, leading to infinite loops. Berkeley DB handles
have completely different semantics from C FILE* pointers.
- The fix for CVE-2014-8121 in glibc was to IGNORE stayopen and always
keep the file open, which is exactly what this patch does for
libnss-db. The patch follows the same mitigation strategy.
- glibc's own nss_db module has been using `keep_db |= 1` (always open)
for years without issue.
Therefore, I do not see any risk of regression in relation to CVE-2014-8121.
I'm aware that libnss-db has broader challenges in Debian right now:
- The package has been orphaned since 2011 maintained only through QA
uploads.
- There is a serious/RC bug (#1121575 [6]) because libnss-db depends on
libdb5.3 (Berkeley DB 5.3), which is itself unmaintained upstream and
being removed from Debian (#1117120).
- There is active work to make the package upstreamable and to address
the db5.3 dependency, but that effort is going to take considerable
time to complete.
- Ongoing effort to include libnss-db from glibc [7] [8].
Given that the larger restructuring work is ongoing and will take a while,
I'd like to see this performance patch merged independently and ahead of
that effort. The patch is minimal (a one-line change), low-risk, and
addresses a real-world performance problem that users are hitting today.
It can be landed in the current codebase without conflicting with any
future db5.3 migration or upstream adoption work.
Given that libnss-db is an orphaned package maintained by the Debian QA
team,
and this is a straightforward performance improvement that aligns with
glibc's
own behavior, I'd like to check if you'd be willing to accept this patch
[1],
and would be able to do NW upload for Debian.
Please let me know if this is possible and/or have any questions for me.
Thanks,
Ponnuvel Palaniyappan
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101371
[2] https://bugs.launchpad.net/ubuntu/+source/libnss-db/+bug/2121543
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=33558
[4] https://marc.info/?l=glibc-alpha&m=176102749124614&w=3
[5] https://security-tracker.debian.org/tracker/CVE-2014-8121
[6] https://bugs.debian.org/1121575
[7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132249
[8] https://salsa.debian.org/glibc-team/glibc/-/merge_requests/38
