Date: Thu, 24 Dec 2020 01:25:37 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252094] nss "compat": getpw(nam|uid)_r(3) inadvertently reset next entry key for getpwent_r(3) Message-ID: <bug-252094-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252094 Bug ID: 252094 Summary: nss "compat": getpw(nam|uid)_r(3) inadvertently reset next entry key for getpwent_r(3) Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: ietf-dane@dukhovni.org Created attachment 220877 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D220877&action= =3Dedit Proposed patch When testing the Haskell "unix" library, an unexpected interaction was encountered between interleaved calls to getpwent_r(3) and either of getpwnam_r(3) and getpwuid_r(3), which manifests only in the default configuration with nsswitch.conf having "passwd: compat". Changing to "pas= swd: files" resolves the issue. The reason is that the "compat" code incorrectly mutates the "global" (real= ly thread-local) st->keynum not only when doing a getpwent() walk, but also wh= en calling getpwnam() or getpwuid(), which should not mutate the keynum (and d= on't in files_passwd, but inadvertently do in compat_passwd). A similar issue is present with getgr(nam|gid)_r(3) vs. getgrent_r(3), but there the problem is more entrenched, because the walk position for getgren= t() is just an implicit file offset into the open group file. Fixing this might require adding appropriate fseeko()/ftello() calls so that getgrent_r(3) can resume at the expected offset even after an intervening call to getgrnam_r(= 3), ... Alternatively, it might simply make sense to not bother using the alre= ady open file with getgr(nam|uid)_r(3), file systems are sufficiently fast these days, and the relevant metadata will be in the cache... I'm willing to contribute a separate fix for the group case, but first would like to get feedback on the passwd case, and preferred solution for the gro= up case. Link to the Haskell issue: <https://github.com/haskell/unix/pull/169>. This can affect any language or system that interleaves multiple user-level "gre= en" threads within a single OS thread. Or just for some chooses to interleave getpwnam() calls in the middle of walking the list with getpwent() (somewhat less like, but not manifestly invalid). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252094-227>