Bug 699530

Summary:	Users with a local group as their primary GID are denied access by the simple access provider
Product:	Red Hat Enterprise Linux 6	Reporter:	Stephen Gallagher <sgallagh>
Component:	sssd	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED ERRATA	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	benl, dpal, grajaiya, jgalipea, jhrozek, kbanerje, prc
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.5.1-35.el6	Doc Type:	Bug Fix
Doc Text:	Cause: The "simple" access provider in SSSD required that user's primary group is available to SSSD. Consequence: The "simple" access provider did not work for users whose primary group was a local group stored in /etc/group because SSSD only handles remote groups. Fix: The failure to find user's primary group in the simple access provider is no longer treated as fatal. Result: Users with local primary group are handled correctly by the simple access provider	Story Points:	---
Clone Of:
Clones:	700168 (view as bug list)		Environment:
Last Closed:	2011-12-06 16:38:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	700168

Description Stephen Gallagher 2011-04-25 20:46:20 UTC

Description of problem:
The root cause of the problem is that his users have a non-LDAP primary group. So when we attempt to look up their primary group in the cache for authorization, we cannot find it and throw an error.

We need to make the primary group lookup a best-effort.

Patch is available upstream.

Version-Release number of selected component (if applicable):
sssd-1.5.1-30.el6

How reproducible:
Every time

Steps to Reproduce:
1. Create a user in LDAP with a primary GID set to a non-LDAP group (such as the "users" group (ID 100).
2. Also add the user to a legitimate ldap group (e.g. ldapusers)
2. Set up SSSD to use the simple access provider
3. Use 'simple_allow_groups = ldapusers'
  
Actual results:
User is denied.
/var/log/secure reports "System Error"

Expected results:
User is granted access

Additional info:
https://fedorahosted.org/sssd/ticket/853

Comment 3 Kaushik Banerjee 2011-09-07 17:09:57 UTC

Verified in build:

# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 49.el6                        Build Date: Mon 29 Aug 2011 08:26:38 PM IST
Install Date: Wed 31 Aug 2011 07:01:44 AM IST      Build Host: x86-010.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-49.el6.src.rpm
Size        : 3549339                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon

Comment 4 Jakub Hrozek 2011-10-26 16:16:33 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: The "simple" access provider in SSSD required that user's primary group is available to SSSD.
Consequence: The "simple" access provider did not work for users whose primary group was a local group stored in /etc/group because SSSD only handles remote groups.
Fix: The failure to find user's primary group in the simple access provider is no longer treated as fatal.
Result: Users with local primary group are handled correctly by the simple access provider

Comment 5 errata-xmlrpc 2011-12-06 16:38:13 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1529.html