-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat 13 Apr 2013 04:18:25 PM EDT, Harry Sutton wrote:
On 04/11/2013 10:59 AM, Simo Sorce wrote:
> On Thu, 2013-04-11 at 10:22 -0400, Sutton, Harry (GSSE) wrote:
>> On 04/11/2013 09:55 AM, Simo Sorce wrote:
>>> Because the PAM stack is completely separate from the NSS
>>> stack, although we suggest people to not do this normally you
>>> can use an option in nsswitch.conf to avoid falling through
>>> NSS modules during the initgroups call to avoid paying the
>>> penalty for local users.
>>>
>>> The option is called 'initgroupss', where you can list files
>>> and sss as databases.
>>>
>>> Note that we normally *do not* recommend this option, here is
>>> a discussion of the why:
>>>
https://bugzilla.redhat.com/show_bug.cgi?id=835612
>>>
>>> Simo.
>>>
>> Thanks, that works as a workaround. If I can get an answer to
>> my earlier question about sss_aduser in a LOCAL domain I'll
>> consider migrating completely to sssd for local and domain
>> logins, at which point I can remove this modification to
>> nsswitch.
Okay, so I think my response was premature; it turns out that I
had disabled sssd temporarily, and that's why it appeared that
making this change had removed the undesirable behavior.
But when I re-enabled the sssd daemon, the time delay in logins
returned. And further reading of the bug you referenced still
leaves me uncertain as to why this feature would be causing delayed
local logins, primarily because the local user account and network
user account are mutually exclusive: there is no network user
account named 'sutton' (verified after joining the domain with
'getent passwd sutton') and there is no local user account named
'suttonh'.
The local (sutton) user is, by long-standing Red Hat tradition, the
only member of the group 'sutton', while the network (suttonh) user
is a member of the 'domain users' group. So if the initgroups line
in nsswitch has 'files' as the first choice, and the group 'sutton'
exists in the local /etc/group file, why isn't it succeeding
promptly?
The reason it doesn't succeed promptly is because initgroups() is
meant to return the complete list of any group that the user belongs
to. Just because the user is local, that does not mean that he cannot
belong to network groups. (A classic example of this is companies
keeping a 'dbusers' group stored in LDAP that references a user like
'oracle' that is created and maintained locally on each system).
The classic behavior of initgroups() is to try each and every database
provided at the groups: line in nsswitch in order to determine if this
user is a member of any groups in that database.
On recent Fedora systems, glibc has added a new syntax to allow you to
add an initgroups: line in nsswitch.conf and specify that you want
initgroups() to stop at the first match instead of trying all results.
This feature is not present on Fedora prior to 17 or any shipping
version of Red Hat Enterprise Linux. Also note: In Fedora 18 and
later, glibc changed this to be the default behavior if the
initgroups: line is unspecified, but this was a backwards-incompatible
change, so authconfig is supposed to be reverting it to the classic
behavior when it is used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlFtnMAACgkQeiVVYja6o6OTjgCfY4I8qelfuc1Lexlud3kdEjZ9
yNAAnAoPpIkUQsveokdt1F55decxSe7s
=UrCJ
-----END PGP SIGNATURE-----