Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 809676

Summary: Mock and FreeIPA group detection issues.
Product: [Fedora] Fedora Reporter: David Brown <david.brown>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dpal, mebrown, myllynen, rcritten, sgallagh, ssorce, williams
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-26 00:23:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Brown 2012-04-04 02:53:48 UTC
Description of problem:
So the code that mock uses to detect whether the running user is a member of
the mock group doesn't work when using FreeIPA to manage users. The call in question is any call to grp.getgrall() this doesn't return group information for FreeIPA managed users.

Version-Release number of selected component (if applicable):
# rpm -qa | grep -e sssd -e mock
mock-1.1.21-1.fc16.noarch
sssd-client-1.8.1-7.fc16.x86_64
sssd-1.8.1-7.fc16.x86_64

How reproducible:
Pretty easy to reproduce.

Steps to Reproduce:
1. Install FreeIPA and mock
2. Add mock group with appropriate GID to FreeIPA
3. Add build user to FreeIPA and add him to the mock group
4. Login with the build user and try to run mock.
  
Actual results:
mock returns the user isn't part of the mock group

Expected results:
mock should have built the src rpm I gave it.

Additional info:
There's a work around by adding `enumerate = true' to the client sssd.conf file. However, after some IRC discussion with the FreeIPA guys the work around can't happen by default since it has scalability issues when there's 100k or so groups in ldap.

The odd thing about the calls to grp.getgrall() is that the groups returned are used to set the groups when mock switches to the users UID (I think). I'm wondering why all the groups a user is a member of need to be set. Could the mock group just be set and moved on? Just a thought.

The FreeIPA guys will have to chime in and provide more information.

Comment 1 Clark Williams 2012-06-07 20:45:34 UTC
Is there some way we can figure out from mock that the account is FreeIPA managed?

Comment 2 David Brown 2012-06-07 21:27:17 UTC
Not that I know of, however, I'm not sure why you would want to go down that path.

This problem could persist with any kind of remote account management database, ldap, smb, etc.

The question I have still stands though, why does mock need to set all the groups for the user? you could remove grp.getgrall() entirely and just set the mock group. What issues would that bring up though?

Comment 3 Dmitri Pal 2012-06-07 21:34:01 UTC
It seems like mock should be able to just use the underlying libc calls that call NSS stack. If this is done properly all the rest plumbing underneath (SSSD -> IPA) would just work as well as any other remote source of identities.

Comment 4 David Brown 2012-06-07 21:39:50 UTC
(In reply to comment #3)
> It seems like mock should be able to just use the underlying libc calls that
> call NSS stack. If this is done properly all the rest plumbing underneath
> (SSSD -> IPA) would just work as well as any other remote source of
> identities.

The python grp.getgrall() is the standard way to get this information from the python level using the standard NSS stack. However, when you have 100k groups which the FreeIPA guys are concerned about iterating over all those groups to collect every group the user is a member of seems pointless to me.

Why does mock care if I'm part of the cdrom and video groups to build the rpm I told it to build?

Comment 5 Clark Williams 2012-06-07 22:10:18 UTC
pretty sure we did this in a (possibly misguided) attempt to not break anything that depends on group membership. 

I'll try calling os.setgroups() with just the mock gid and see if that causes issues with my testing. If not I'll spin a build with that code and we'll see if it breaks anyone else.

Comment 6 Simo Sorce 2012-06-08 03:01:15 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > It seems like mock should be able to just use the underlying libc calls that
> > call NSS stack. If this is done properly all the rest plumbing underneath
> > (SSSD -> IPA) would just work as well as any other remote source of
> > identities.
> 
> The python grp.getgrall() is the standard way to get this information from

Actually grp.getgrall() is a very bad way to do it.

> the python level using the standard NSS stack. However, when you have 100k
> groups which the FreeIPA guys are concerned about iterating over all those
> groups to collect every group the user is a member of seems pointless to me.

and normally you also do not really get all groups, as we do not perform enumeration by default, so groups can have missing memberships if you go the getgrall() call.

> Why does mock care if I'm part of the cdrom and video groups to build the
> rpm I told it to build?

Properly representing the user is important, for that you should use the os.initgroups() call (new in python 2.7) to get thjse users list of gids.
That will call the correct underlying nsswitch interface. The initgroups call is handled efficiently by nsswitch and will not result in overkill queries when a machine is connected to large domains.

So please use os.initgroups() + os.setgroups()

HTH.

Comment 7 Clark Williams 2012-06-08 19:03:01 UTC
Using a Python 2.7 call is also problematic. Mock has to run on Python 2.4 (RHEL5) and python 2.6 (RHEL6) in addition to the various Fedoras that are live (F15, F16, F17 and rawhide). 

So I'm not very keen on making that change. I suppose I could add some logic to attempt to call os.initgroups inside a try/except block and to fall back to the current logic if it's not there.

Comment 8 Stephen Gallagher 2012-06-08 19:07:31 UTC
That's probably going to be your best bet. SSSD/FreeIPA isn't the only situation where you would hit this problem. By default, winbind does not enumerate all users and groups either, so this would fail if someone was storing their group memberships in Active Directory as well.

Comment 9 Clark Williams 2012-06-09 13:55:50 UTC
Ok, before I embark on a redesign of the initialization code, let's make sure we have a consensus on what we want to happen. We have two basic scenarios regarding groups:

1. Set the chroot process to have the same set of supplementary groups as the invoking user
2. Set the chroot process to only have the 'mock' group as a supplementary group

Evidently, we are not doing things correctly for #1. I've tried #2 in a private branch and it passes the mock test suite (make check), but that's pretty basic. 

After looking at this for a bit, I'm actually leaning towards #2, which has the benefit of being simple and works for all supported distros. Can anyone think of a reason *why* we want to have a list of supplemental groups besides mock?

Comment 10 Simo Sorce 2012-06-11 13:43:35 UTC
> After looking at this for a bit, I'm actually leaning towards #2, which has
> the benefit of being simple and works for all supported distros. Can anyone
> think of a reason *why* we want to have a list of supplemental groups
> besides mock?

Yes, first of all, the case where supplementary groups are present should be rare enough, so in pratice you should end up with just mock in most situtations, however if someone needs to add mock to a supplementary group in order to allow the mock user some operation that should just work. Having to hack the code is not a good user interface imo.

If you use the initgroups call you should have no major issue, as in most cases the additional remote backends will return very quickly with no results.

Comment 11 David Brown 2012-06-11 14:38:41 UTC
To comment on the last statement an equivalent question would be to ask, "Would a package builder ever require himself to be part of a supplementary group in order to build an RPM?" That thought would bring to question the packager and the build system for the code to require that situation.

I guess my only reason to make it only the mock group would be simply QA enforcement.

Either solution would be fine by me. Since both would fix the issues I've been having.

Comment 12 David Brown 2012-06-11 14:40:20 UTC
(In reply to comment #11)
> To comment on the last statement 

Last comment being Clark's comment.

Comment 13 Fedora Update System 2012-06-21 21:55:35 UTC
mock-1.1.23-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mock-1.1.23-1.fc15

Comment 14 Fedora Update System 2012-06-21 21:56:10 UTC
mock-1.1.23-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.23-1.el6

Comment 15 Fedora Update System 2012-06-21 21:56:20 UTC
mock-1.1.23-2.1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.23-2.1.fc17

Comment 16 Fedora Update System 2012-06-21 21:56:31 UTC
mock-1.0.30-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.30-1.el5

Comment 17 Fedora Update System 2012-06-21 21:56:44 UTC
mock-1.1.23-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.23-1.fc16

Comment 18 Fedora Update System 2012-07-19 22:36:06 UTC
Package mock-1.0.30-1.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mock-1.0.30-1.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6429/mock-1.0.30-1.el5
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2012-07-27 22:11:55 UTC
mock-1.1.24-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.24-1.fc16

Comment 20 Fedora Update System 2012-07-27 22:12:15 UTC
mock-1.1.24-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.24-1.el6

Comment 21 Fedora Update System 2012-07-27 22:12:32 UTC
mock-1.1.24-2.1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.24-2.1.fc17

Comment 22 Fedora Update System 2012-07-27 22:12:51 UTC
mock-1.0.31-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.31-1.el5

Comment 23 Fedora Update System 2012-07-31 20:30:37 UTC
mock-1.1.25-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.25-1.fc17

Comment 24 Fedora Update System 2012-07-31 20:31:00 UTC
mock-1.1.25-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.25-1.el6

Comment 25 Fedora Update System 2012-07-31 20:31:28 UTC
mock-1.0.32-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.32-1.el5

Comment 26 Fedora Update System 2012-07-31 20:31:52 UTC
mock-1.1.25-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.25-1.fc16

Comment 27 Fedora Update System 2012-08-06 18:46:21 UTC
mock-1.1.26-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.26-1.fc17

Comment 28 Fedora Update System 2012-08-06 18:46:52 UTC
mock-1.1.26-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.26-1.el6

Comment 29 Fedora Update System 2012-08-06 18:47:21 UTC
mock-1.1.26-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.26-1.fc16

Comment 30 Fedora Update System 2012-08-06 18:47:52 UTC
mock-1.0.34-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.34-1.el5

Comment 31 Fedora Update System 2012-08-15 21:49:08 UTC
mock-1.1.26-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.26-2.fc17

Comment 32 Fedora Update System 2012-08-17 11:52:44 UTC
mock-1.1.26-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.26-2.el6

Comment 33 Fedora Update System 2012-08-17 11:54:06 UTC
mock-1.1.26-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.26-2.fc16

Comment 34 Fedora Update System 2012-08-26 00:23:14 UTC
mock-1.1.26-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 35 Fedora Update System 2012-09-14 15:27:37 UTC
mock-1.1.27-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.27-2.el6

Comment 36 Fedora Update System 2012-09-14 15:28:42 UTC
mock-1.1.27-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.27-2.fc16

Comment 37 Fedora Update System 2012-09-14 15:29:36 UTC
mock-1.0.35-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.35-1.el5

Comment 38 Fedora Update System 2012-09-14 15:30:44 UTC
mock-1.1.27-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.27-2.fc17

Comment 39 Fedora Update System 2012-11-01 21:09:42 UTC
mock-1.1.28-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mock-1.1.28-1.el6

Comment 40 Fedora Update System 2012-11-01 21:11:00 UTC
mock-1.1.28-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc18

Comment 41 Fedora Update System 2012-11-01 21:12:11 UTC
mock-1.0.36-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mock-1.0.36-1.el5

Comment 42 Fedora Update System 2012-11-01 21:13:19 UTC
mock-1.1.28-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc17

Comment 43 Fedora Update System 2012-11-01 21:14:26 UTC
mock-1.1.28-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mock-1.1.28-1.fc16

Comment 44 Fedora Update System 2012-11-15 02:33:18 UTC
mock-1.1.28-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 45 Fedora Update System 2012-11-15 02:35:26 UTC
mock-1.1.28-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 46 Fedora Update System 2012-11-20 19:37:52 UTC
mock-1.0.36-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.