Bug 1408508
| Summary: | If Advisory exists in multiple repos yum only uses one of the package lists | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | nrhuff | ||||
| Component: | Pulp | Assignee: | satellite6-bugs <satellite6-bugs> | ||||
| Status: | CLOSED ERRATA | QA Contact: | jcallaha | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.2.6 | CC: | aperotti, asahni, bkearney, bmbouter, cshereme, daniele, daviddavis, dkliban, emrakova, ggainey, ggatward, gkonda, hmore, ipanova, james.antill, jcallaha, jentrena, kdixon, ktordeur, mdomonko, mhrivnak, mmccune, mshimura, nrhuff, pcreech, pmoravec, rchan, ttereshc, xdmoon, zhunting | ||||
| Target Milestone: | Unspecified | Keywords: | PrioBumpField, PrioBumpGSS | ||||
| Target Release: | Unused | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | pulp-rpm-2.8.7.14-2 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1459336 (view as bug list) | Environment: | |||||
| Last Closed: | 2017-06-20 17:53:27 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1353215 | ||||||
| Attachments: |
|
||||||
|
Description
nrhuff
2016-12-23 23:07:48 UTC
Hello, we have addressed few related issues in RHEL-7.3. Are you running the latest yum package (yum-3.4.3-150.el7.noarch)? Yes yum version is yum-3.4.3-150.el7.noarch (In reply to nrhuff from comment #0) Hi nrhuff, do you expect that # yum updateinfo list sudo will return RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.i686 ? It is not expected to do so, no matter that sudo-devel is a sub-package of sudo. You should run # yum updateinfo list sudo* instead. These are the results on my RHEL-7.3 system: # rpm -qa sudo\* sudo-1.8.6p7-20.el7.x86_64 sudo-devel-1.8.6p7-20.el7.x86_64 # yum updateinfo list Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64 RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64 updateinfo list done # yum updateinfo list sudo Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64 updateinfo list done # yum updateinfo list sudo-devel Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64 updateinfo list done # yum updateinfo list sudo\* Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64 RHSA-2016:2872 Moderate/Sec. sudo-devel-1.8.6p7-21.el7_3.x86_64 updateinfo list done The above seem correct to me. I don't have sudo-devel installed
# rpm -qa sudo\*
sudo-1.8.6p7-20.el7.x86_64
I would expect that 'yum update info list sudo' should return RHSA-2016:2872 since the package list contains sudo-1.8.6p7-21.el7_3.x86_64.rpm.
When I run yum updateinfo sudo I get
# yum updateinfo sudo
Loaded plugins: package_upload, priorities, product-id, search-disabled-repos,
: subscription-manager
AHC_AHC_RHEL_7_AHC_x86_64 | 2.1 kB 00:00
AHC_EPEL_RHEL_7_EPEL_x86_64 | 2.1 kB 00:00
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64 | 2.1 kB 00:00
rhel-7-server-optional-rpms/x86_64 | 2.0 kB 00:00
rhel-7-server-rpms/x86_64 | 2.0 kB 00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64 | 2.1 kB 00:00
updateinfo info done
# yum updateinfo sudo\*
Loaded plugins: package_upload, priorities, product-id, search-disabled-repos,
: subscription-manager
AHC_AHC_RHEL_7_AHC_x86_64 | 2.1 kB 00:00
AHC_EPEL_RHEL_7_EPEL_x86_64 | 2.1 kB 00:00
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64 | 2.1 kB 00:00
rhel-7-server-optional-rpms/x86_64 | 2.0 kB 00:00
rhel-7-server-rpms/x86_64 | 2.0 kB 00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64 | 2.1 kB 00:00
updateinfo info done
If I run 'yum update --security' I get
--> sudo-1.8.6p7-21.el7_3.x86_64 from rhel-7-server-rpms removed (updateinfo)
Even without sudo-devel, this is not an issue for me either. # rpm -qa sudo\* sudo-1.8.6p7-20.el7.x86_64 # yum updateinfo list sudo\* Loaded plugins: product-id, search-disabled-repos, subscription-manager RHSA-2016:2872 Moderate/Sec. sudo-1.8.6p7-21.el7_3.x86_64 updateinfo list done (In reply to nrhuff from comment #6) > If I run 'yum update --security' I get > --> sudo-1.8.6p7-21.el7_3.x86_64 from rhel-7-server-rpms removed > (updateinfo) This is weird and shouldn't really happen. Sadly, there's no relevant debugging output to be enabled for remove_txmbrs() that's responsible for this, so could you please: 1) attach the respective updateinfo files from /var/cache/yum for both rhel-7-server-rpms and rhel-7-server-optional-rpms and 2) try running # yum --noplugins --disablerepo=* --enablerepo=rhel-7\* updateinfo sudo Thanks! (In reply to Michal Domonkos from comment #7) > 1) attach the respective updateinfo files from /var/cache/yum for both > rhel-7-server-rpms and rhel-7-server-optional-rpms and Please disregard the above part and don't attach the updateinfo files directly to this BZ. I didn't realize they contain RHEL errata information that shouldn't be redistributed: https://access.redhat.com/help/terms/ If you still experience the issue even after trying step 2), please consider escalating this bug through your support representative. They will also help you share these files securely with us. # yum --noplugins --disablerepo=* --enablerepo=rhel-7\* updateinfo sudo
rhel-7-server-optional-rpms/x86_64 | 2.0 kB 00:00:00
rhel-7-server-rpms/x86_64 | 2.0 kB 00:00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64 | 2.1 kB 00:00:00
updateinfo info done
If I disable the optional repo I get what I would expect.
# yum --noplugins --disablerepo=rhel-7-server-optional-rpms updateinfo sudo
AHC_AHC_RHEL_7_AHC_x86_64 | 2.1 kB 00:00:00
AHC_EPEL_RHEL_7_EPEL_x86_64 | 2.1 kB 00:00:00
AHC_Zabbix_RHEL_7_Zabbix_2_4_x86_64 | 2.1 kB 00:00:00
mysql_ent | 2.1 kB 00:00:00
rhel-7-server-rpms/x86_64 | 2.0 kB 00:00:00
rhel-7-server-satellite-tools-6.2-rpms/x86_64 | 2.1 kB 00:00:00
===============================================================================
Moderate: sudo security update
===============================================================================
Update ID : RHSA-2016:2872
Release : 0
Type : security
Status : final
Issued : 2016-12-06 09:43:08 UTC
Updated : 2016-12-06 09:43:09 UTC Bugs : 1372830 - CVE-2016-7032 sudo: noexec bypass via system() and popen()
: 1384982 - CVE-2016-7076 sudo: noexec bypass via wordexp()
CVEs : CVE-2016-7032
: CVE-2016-7076
Description : The sudo packages contain the sudo utility which allows system
: administrators to provide certain users with the
: permission to execute privileged commands, which
: are used for system management purposes, without
: having to log in as root.
:
: Security Fix(es):
:
: * It was discovered that the sudo noexec
: restriction could have been bypassed if
: application run via sudo executed system(),
: popen(), or wordexp() C library functions with a
: user supplied argument. A local user permitted
: to run such application via sudo with noexec
: restriction could use these flaws to execute
: arbitrary commands with elevated privileges.
: (CVE-2016-7032, CVE-2016-7076)
:
: These issues were discovered by Florian Weimer
: (Red Hat).
Severity : Moderate
updateinfo info done
We are on a self-support license so I don't think I can go through a support rep.
It appears this is an issue with the way that Satellite, at least as of version 6.2.6, is generating the updateinfo.xml file. The updateinfo coming from the main RedHat subscription manager works as I would expect. The updateinfo files coming from satellite are slightly different and cause the issue I am seeing. I've managed to reproduce this by setting up a custom Satellite 6.2 instance. The issue really is in the way updateinfo.xml files are generated by Satellite. The same files taken directly from CDN are fine. The way yum handles advisories spanning across multiple repos is by merging their <pkglist> elements by <collection><name> It assumes these names don't overlap between the repos, though, so if it encounters such an overlap, the first version found is used and the second is discarded. Now, Satellite 6.2 serves exactly such updateinfo files. For example, for RHSA-2016:2872, the rhel-7-server-optional-rpms repo contains (probably by an accident) an extra <pkglist> with a <collection><name> being the same as in its rhel-7-server-rpms counterpart, but doesn't actually contain any packages. So if yum reads the -optional repo first, it ignores the same definition in the non-optional repo later on, meaning the internal structure for this advisory won't contain the sudo package at all and yum will fail to match anything against "yum updateinfo sudo" (unless you disable the -optional repo just like the reporter showed in Comment 9). While we could simply fix the merging logic in yum to ignore an empty <collection/> to make this work, this looks more like a bug in Satellite so I'm reassigning it. I did end up opening a support case against Satellite for this. The Case ID is 01771450. Tanya, I think this is probably already fixed by the work you did. Is that right? https://pulp.plan.io/issues/2227 https://github.com/pulp/pulp_rpm/pull/976 Michael, I think this issue is different. Michal, I agree that the generation for the updateinfo.xml may be more sane in terms of not creating empty pkglists. But maybe a merging logic on the yum side is worth improving as well, consider the following scenario: Users can not only mirror repositories but modify them as well. 1. Say, there is a repo A. It consists of 2 packages (P1 and P2) and the advisory ADV which pkglist has 2 packages (P1, P2) in it. 2. User creates two stripped copies of the repo A, so he/she will be able to publish packages P1 and P2 separately in different repositories: - repo A1 contain only package P1 + advisory ADV which pkglist will have only P1 now (because all the packages listed in the advisory should be available in the repository), - repo A2 contain only package P2 + advisory ADV which pkglist will have only P2 now. 3. If for some reason one will configure both repositories A1 and A2 then one of the packages P1 or P2 won't be found by yum according to the logic you described. I am not sure if it is possible to guarantee unique collection names across the repositories. Keep in mind that user ca upload advisory of his own with the conflicting names. What do you think about merging collections with the same name instead of choosing only one? This will solve both empty collection case and the scenario I described above. Any issues or downsides for such approach? Merging sounds like it would be reasonable. But what if we assume that given repo A with advisory ADV, that all packages in the package list must stay with the advisory in order for it to be considered correct? Ultimately, the advisory exists so a user can have confidence that "I installed ADV, and therefore my system is no longer affected by the problem it solves." If someone only installed a subset of the packages that were originally published with it, they would incorrectly believe they had resolved a problem. We want users to keep all of the listed packages with an advisory. I'm not sure what katello enforces, but I think the above is true in terms of what behavior is correct. Hey Tanya, Thanks for the feeback! Comments inline: (In reply to Tanya Tereshchenko from comment #15) > 2. User creates two stripped copies of the repo A, so he/she will be able to > publish packages P1 and P2 separately in different repositories: > - repo A1 contain only package P1 + advisory ADV which pkglist will have > only P1 now (because all the packages listed in the advisory should be > available in the repository), > - repo A2 contain only package P2 + advisory ADV which pkglist will have > only P2 now. Would Satellite rename the <collection>s of ADV in repo A1 and A2 in the updateinfo files automatically (e.g. to the repo A1 and A2 names, respectively, just like we do that on CDN) or would it just leave them intact (e.g. "rhel-7-server-rpms__7Server__x86_64" and "rhel-7-server-optional-rpms__7Server__x86_64")? > 3. If for some reason one will configure both repositories A1 and A2 then > one of the packages P1 or P2 won't be found by yum according to the logic > you described. This depends on the question above. In the former case, yum would combine the two update notices from repo A1 and A2 correctly, seeing both P1 and P2. In the latter case, yum wouldn't find one of them, like you said. > I am not sure if it is possible to guarantee unique collection names across > the repositories. Keep in mind that user ca upload advisory of his own with > the conflicting names. According to this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1302663#c35 it seems that the collections are always named after the repo they're defined in, which is exactly what yum assumes as well. > What do you think about merging collections with the same name instead of > choosing only one? This will solve both empty collection case and the > scenario I described above. Any issues or downsides for such approach? Doing the collection merging in yum would be pretty easy, no downsides come to mind. If it turns out the scenario you described is really a valid one (see my questions inline), we'll happily implement it in yum. Thanks! Thanks Michal! Sorry for the late response (DevConf + DevConf flu afterwards). Pulp (the component we discuss in this BZ) does not modify collection names anyhow right now. Thanks for pointing out to the relevant BZ, though it was a patch and discussion of the RCM's Pulp which is different from the upstream. To solve the current issue it would be enough not to generate empty pkglists which does not make any sense to do anyway. I will add upstream issue to this BZ. As for the collection names. It sounds reasonable to have them constructed in the described way especially if yum relies on that. At the same time I think it should not be solved in the scope of this BZ. I will file an issue upstream and we'll discuss it there. We will reach you in case of any questions Thanks! The Pulp upstream bug status is at NEW. Updating the external tracker on this bug. The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug. The Pulp upstream bug priority is at High. Updating the external tracker on this bug. The Pulp upstream bug status is at ASSIGNED. Updating the external tracker on this bug. The Pulp upstream bug status is at POST. Updating the external tracker on this bug. The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug. All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST. The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug. Just a question when the upstream patch helps or not. Am I right the fix removes the pkglists that are empty (instead of populating them)? If so, is that a proper solution? Assume the pkglist for some errata is empty in repo A because the pkglist is populated in repo B. This is done on a pulp-server (Satellite or Capsule) during createrepo call. After the fix, pkglist in repo A will be removed. What happens if I then register a client machine and enable just repo A but _not_ repo B? Wont it get incomplete metadata (not having pkglist for some errata that is populated in not-enabled repo B)? Pkglists are not empty and won't be removed or anyhow stripped in DB, no changes there. What changed is the way updateinfo.xml is generated, so after applying a fix no empty pkglists will be generated in updateinfo.xml. I am not sure I get your question 100% but there is no impact on pkglist generation between different repositories. If an erratum belongs to both repo A and repo B, then pkglists for both repos will be generated separately and they may differ (packages for RHEL6 and for RHEL7, for example). Hope that helps. The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. The Pulp upstream bug priority is at High. Updating the external tracker on this bug. The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug. All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST. The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug. Verified in Satellite 6.2.10 Snap 4
I followed the instructions detailed in the setup. See attached screenshot for the repositories which all four of these errata were found in.
-bash-4.2# yum updateinfo list
Loaded plugins: package_upload, product-id, search-disabled-repos, subscription-manager
Default_Organization_z-stream_7capsule | 2.1 kB 00:00:00
rhel-7-server-optional-rpms/7Server/x86_64 | 2.0 kB 00:00:00
RHSA-2014:1912 Moderate/Sec. rubygem-rake-0.9.6-22.el7_0.noarch
RHBA-2015:0594 bugfix rubygem-rake-0.9.6-24.el7.noarch
RHBA-2015:1158 bugfix rubygem-rake-0.9.6-25.el7_1.noarch
RHEA-2016:2422 enhancement rubygem-rake-0.9.6-29.el7.noarch
updateinfo list done
for reference, here are the repos enabled on this system.
-bash-4.2# subscription-manager repos --list-enabled
+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: Default_Organization_z-stream_7capsule
Repo Name: 7capsule
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/custom/z-stream/7capsule
Enabled: 1
Repo ID: rhel-7-server-rh-common-rpms
Repo Name: Red Hat Enterprise Linux 7 Server - RH Common (RPMs)
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/rh-common/os
Enabled: 1
Repo ID: rhel-7-server-optional-rpms
Repo Name: Red Hat Enterprise Linux 7 Server - Optional (RPMs)
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/optional/os
Enabled: 1
Repo ID: rhel-server-rhscl-7-rpms
Repo Name: Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/rhscl/1/os
Enabled: 1
Repo ID: rhel-7-server-rpms
Repo Name: Red Hat Enterprise Linux 7 Server (RPMs)
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/$releasever/$basearch/os
Enabled: 1
Repo ID: rhel-7-server-satellite-capsule-6.2-rpms
Repo Name: Red Hat Satellite Capsule 6.2 (for RHEL 7 Server) (RPMs)
Repo URL: https://sat-qe-1.rhq.lab.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/capsule/content/dist/rhel/server/7/7Server/$basearch/sat-capsule/6.2/os
Enabled: 1
Created attachment 1286558 [details]
errata repos
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. https://access.redhat.com/errata/RHBA-2017:1553 *** Bug 1445091 has been marked as a duplicate of this bug. *** |