Bug 815568

Summary:	yum-security does not work with yum makecache and yum -C
Product:	Red Hat Enterprise Linux 6	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	yum	Assignee:	James Antill <james.antill>
Status:	CLOSED ERRATA	QA Contact:	Patrik Kis <pkis>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	ksrot, pkis, pknirsch, zpavlas
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	All
URL:	http://lists.baseurl.org/pipermail/yum-devel/2012-April/009242.html
Whiteboard:
Fixed In Version:	yum-3.2.29-31.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 10:12:39 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 Christoph Anton Mitterer 2012-04-23 21:38:01 UTC

Hi.

This is from http://lists.baseurl.org/pipermail/yum-devel/2012-April/009242.html :

What I do is running the nagios/icinga check_yum plugin periodically as 
non-root (!) user.
That the system is not cluttered with repository caches and because a 
simply yum check-update quite some time I run yum makecache periodically 
as root (!) via cron (every hour).

Now check_yum invokes yum like the following:
/usr/bin/yum --security check-update -C

Which leads as non-root user to the following output and error:
$ /usr/bin/yum --security check-update -C
Loaded plugins: changelog, downloadonly, fastestmirror, keys, 
priorities, protectbase, ps, security, verify
102 packages excluded due to repository priority protections
0 packages excluded due to repository protections
Limiting package lists to security relevant ones


[Errno 13] Permission denied: 
'/var/cache/yum/x86_64/6.2/epel/gen/updateinfo.xml'
$

Strace shows the following:
$ strace -e trace=open /usr/bin/yum --security check-update -C 2>&1 | 
grep EACCES
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("DB_CONFIG", O_RDONLY)             = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/epel/20ea7be5624822f05d7cf61426ffcaf71f2104a5905ccc4880495741ab02a801-primary.sqlite", 
O_RDWR|O_CREAT, 0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/sl/primary.sqlite", O_RDWR|O_CREAT, 
0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/sl-security/primary.sqlite", 
O_RDWR|O_CREAT, 0644) = -1 EACCES (Permission denied)
open("/var/cache/yum/x86_64/6.2/epel/gen/updateinfo.xml", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
$

All these files are root owned and -rw-r--r--.


When I then run
/usr/bin/yum --security check-update -C
as root, and after wards again as non-root user, it works for the 
non-root user (even though the permissions haven't changed. No idea why.



Hope you can provide a fix soon :)

Cheers,
Chris.


btw: I reported this here, as one cannot report bugs in the trac at http://yum.baseurl.org/ (missing permissions).

Comment 2 Christoph Anton Mitterer 2012-04-23 23:17:57 UTC

I tried to workaround that issue, by manually decompressing that file to ./gen
(as root and before I do the check as user).

But this does not (!!) help?!
Also, the file is already there (even though with an older timestamp and
therefore probably an older version of the file).

So how does check-update find out whether it needs to decompress that file or
not?
Cause when I ran /usr/bin/yum --security check-update -C as root before, then
it works as user, too.
There must be some condition that is now met, that yum no longer tries to
decompress it.


Cheers,
Chris.

Comment 3 Zdeněk Pavlas 2012-04-24 07:22:28 UTC

> There must be some condition that is now met, that yum no longer tries to
decompress it.

Hi, Yum compares timestamps, they have to match.  If you try to work this around by decompressing manually, adding "touch -r updateinfo.xml.gz gen/updateinfo.xml" should work.

Comment 4 James Antill 2012-04-24 14:15:45 UTC

 The easy way to work around it for all things is to use the data. Eg. for updateinfo change your cron to do:

yum makecache && yum updateinfo

...at least until we find a good way to fix this.

Comment 5 Christoph Anton Mitterer 2012-06-25 23:35:07 UTC

Hey...

Anything new here (read: chances for a real fix?) :-)

Cheers,
Chris.

Comment 6 James Antill 2012-07-31 20:09:11 UTC

Ok, posted a hacky fix for this upstream.

Comment 10 Christoph Anton Mitterer 2012-10-05 23:57:05 UTC

Hi James.

What is "yum updateinfo" actually doing? I haven't found it in the manpage.

So I guess this is being backported now to RHEL 6? When can we expect it there?


Thanks.

Comment 11 Karel Srot 2012-10-10 11:37:14 UTC

(In reply to comment #10)
> Hi James.
> What is "yum updateinfo" actually doing? I haven't found it in the manpage.

Hi,
you need to have yum-plugin-security installed, then check "man yum-security".

Comment 12 Christoph Anton Mitterer 2012-10-12 00:36:56 UTC

Hi

Uhm thanks, but that manpage does not really explain what happens, does it?

It merely tells that some file is downloaded, but not whether I (regularly) need to run updateinfo, in order to have all informations about security updates.
So is that the case?


Actually it seems to not even tell that one can run just "yum updateinfo"... in the manpage it shows just up with a 2nd argument info/list/summary.

Cheers,
Chris.

Comment 13 Karel Srot 2012-10-12 07:25:01 UTC

Hi,

(In reply to comment #12)
> Hi
> Uhm thanks, but that manpage does not really explain what happens, does it?
> 
> It merely tells that some file is downloaded, but not whether I (regularly)
> need to run updateinfo, in order to have all informations about security
> updates.
> So is that the case?

the information is taken from the updateinfo.xml file which is part of the repository. If you have up-to-date metadata, you have also recent information. If you want to be sure, refresh the yum cache manually (e.g. yum makecache). Otherwise you can rely on yum itself to fetch recent metadata when available.

> Actually it seems to not even tell that one can run just "yum updateinfo"...
> in the manpage it shows just up with a 2nd argument info/list/summary.

Yes, the summary command is the default.

I have filed a bug 865694  addressing some errors in the man page. Please, add a comment if I have missed something. Thank you in advance.

Comment 15 Christoph Anton Mitterer 2012-12-04 00:05:04 UTC

Should this already work in RHEL 6.3 now? Cause it seems not to.

Thx,
Chris.

Comment 16 Karel Srot 2012-12-04 07:06:23 UTC

Hello Chris, 
this bug will be fixed in RHEL 6.4.

Comment 18 errata-xmlrpc 2013-02-21 10:12:39 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-2013-0406.html