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: | mock | Assignee: | Clark Williams <williams> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | 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
Is there some way we can figure out from mock that the account is FreeIPA managed? 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? 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. (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? 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. (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. 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. 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. 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? > 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.
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. (In reply to comment #11) > To comment on the last statement Last comment being Clark's comment. 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 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 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 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 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 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). 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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 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 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 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 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 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 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 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 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 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. 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. 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. |