[9083] in athena10
[Debathena] #1143: nss_nonlocal allegedly breaks with recent glibc
daemon@ATHENA.MIT.EDU (Debathena Trac)
Mon May 28 17:26:30 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: geofft@MIT.EDU
Date: Mon, 28 May 2012 21:26:24 -0000
Reply-To:
Message-ID: <042.2f749592a6c626fcf8b94668c51e6c95@mit.edu>
Content-Transfer-Encoding: 8bit
#1143: nss_nonlocal allegedly breaks with recent glibc
-----------------------+----------------------------------
Reporter: geofft | Owner:
Type: defect | Status: new
Priority: high | Milestone: Quantum Quetzalcoatl
Component: -- | Keywords:
Upstream bug: |
-----------------------+----------------------------------
In the discussion on sssd-devel about security equivalent to nss-nonlocal,
they
[http://thread.gmane.org/gmane.linux.redhat.sssd.devel/9645/focus=9674
pointed out] that there are some changes to the initgroups interface that
affect our abuse of internal glibc APIs.
[http://thread.gmane.org/gmane.linux.redhat.sssd.devel/9645/focus=9681
This message] has some more details about a new option, which sounds like
a relevant part of the change:
> However, recently glibc added an option so that you can segregate
> initgroups too. In general we try not to use it becaus ein many cases
> people do want to have the memberships calculated through all group
> backends.
> However if you enable "initgroupos: files sss", the getgrouplist call do
> not continue past files into sss if entries are found in files.
> I am not sure I like this option, as it is rather new, undocumented, and
> the semantics may not be really useful, but you may want to experiment
> with it if you have a new enough glibc. (Was committed to glibc upstream
> repo on may 10 2011)
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1143>
Debathena <http://debathena.mit.edu>
MIT Debathena Project