This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16181] New: innetgr is likely to miss entries in nscd and other multi-thread contexts
- From: "aoliva at sourceware dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 18 Nov 2013 00:12:16 +0000
- Subject: [Bug libc/16181] New: innetgr is likely to miss entries in nscd and other multi-thread contexts
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16181
Bug ID: 16181
Summary: innetgr is likely to miss entries in nscd and other
multi-thread contexts
Product: glibc
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: aoliva at sourceware dot org
CC: drepper.fsp at gmail dot com
innetgr iterates over netgroup entries in nss backends without any form of
locking. Concurrent calls of ninnetgr or other uses of
setnetgrent/getnetgrent/endnetgrent are likely to interfere destructively and
miss entries, even if getnetgrent_r is implemented safely in individual
backends.
It might make sense to add innetgr as an optional nss backend interface, along
the lines of initgroups, falling back to some form of mutual exclusion around
the use of each nss backend.
(This reminds me that some initgroups fallback implementation that iterated
over groups with getgrent_r, that I reviewed years ago, wasn't safe in some nss
backend, so it occasionally missed groups in concurrent scenarios; I'm pretty
sure I wrote a patch that introduced locking back then, but I don't know
whether the problem remains in current glibc versions; the patch is attached to
the Red Hat bugzilla bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=706571 )
--
You are receiving this mail because:
You are on the CC list for the bug.