This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16181] New: innetgr is likely to miss entries in nscd and other multi-thread contexts


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]