Bug 167691 - yum check-update fails when running without root privileges
yum check-update fails when running without root privileges
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-07 04:58 EDT by Kasper Dupont
Modified: 2014-01-21 17:52 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-18 16:20:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kasper Dupont 2005-09-07 04:58:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.1.1.legacy

Description of problem:
When running yum check-update to check if there are any updates I get an error message.

Version-Release number of selected component (if applicable):
yum-2.3.2-7

How reproducible:
Always

Steps to Reproduce:
1. Log in as non root user
2. Run the command: yum check-update


Actual Results:  
Setting up repositories
Cannot access repository dir //var/cache/yum/updates-released

Expected Results:  yum should report if there are any updates which needs to be installed.

Additional info:

Being able to check for updates without root privileges is important as some people rarely log in as root and thus might go for a long time without knowing updates needs to be installed. This bug affects FC3 as well, though on FC3 you can use rhn-applet instead which will provide the necesarry information without root privileges.
Comment 1 Jeremy Katz 2005-09-21 13:52:46 EDT
I can't reproduce this with all the FC4 updates installed.  Does it still occur
with yum 2.4.0?
Comment 2 Kasper Dupont 2005-09-22 01:53:56 EDT
[kasperd@erwin:pts/0:~] rpm -q yum
yum-2.4.0-0.fc4
[kasperd@erwin:pts/0:~] yum check-update
Setting up repositories
Cannot access repository dir //var/cache/yum/updates-released
Error: Cannot access repository dir //var/cache/yum/updates-released
[kasperd@erwin:pts/0:~] 
Comment 3 Jeremy Katz 2005-09-22 13:37:19 EDT
What does ls -l /var/cache/yum show?
Comment 4 Kasper Dupont 2005-09-24 06:14:15 EDT
/var/cache/yum was empty, but after running a "yum whatprovides" command as root
some entries were created. Now yum no longer give me an error message, now
instead I get outdated information. So now it may in fact say no updates are
required even if they are, which is even worse.
Comment 5 Seth Vidal 2005-09-30 00:41:31 EDT
The error you are receiving is that yum cannot download and parse the data if it
doesn't have a place to write the data out to. Since you're not root it can't
write to /var/cache/yum

why is this such a problem?
Comment 6 Kasper Dupont 2005-09-30 01:18:54 EDT
It is a problem because people don't log in as root unless there are updates to
install. The way it works now yum will keep telling that there are no updates,
so a lot of system never gets updated. And this is a regression compared to FC1,
FC2, and FC3 in all of which rhn-applet would provide correct information about
the required updates.
Comment 7 Seth Vidal 2005-09-30 08:16:09 EDT
having a non-root user be able to modify the metadata in the root-owned location
is :
1. extremely unsafe
2. just plainly a bad idea

now if you want to have a regular metadata reader that updates the system
metadata at normal intervals so anyone can see it - then that might be something
that happens. But making the metadata modifiable by a random user is a non-starter.
Comment 8 Kasper Dupont 2005-09-30 08:41:17 EDT
I never said the user should be able to modify the metadata. I only said yum
should produce the correct output. I don't care how it works as long as the
produced output is correct. Rhn-applet was able to do that, yum should be able
to as well.

There are at least two ways to achieve that.
1. Download updated information from the server and don't store it locally (I
think that is how rhn-applet did.
2. Install yum with set group id to a group with write priveleges to the directory.

A periodic download of new metadata would help a bit, but it still doesn't
provide correct output if new updates where released since the last download of
metadata. Possibly the best solution is to have an hourly cron job downloading
metadata and have yum download any more resent metadata without saving it.
Comment 9 Andy Hudson 2006-02-25 10:53:02 EST
I'm still getting this error when using FC5 T3 - is there a way to prevent
non-root users from using the check-update option rather than causing them to
worry about nothing?

I agree with Kasper - it would be worthwhile allowing non-root users to be able
to at least see what updates are available before switching to root and
installing them.
Comment 10 Seth Vidal 2006-02-27 22:22:06 EST
I disagree - think about the use case:

1. user runs yum check-update, they download the metadata into a tmp dir and get
the list of updates
2. the user sees that there are updates, sudo's to run yum update
3. the metadata is downloaded AGAIN and parsed AGAIN to do the real root yum update.

It's a waste of time and bandwidth, isn't it?
Comment 11 Kasper Dupont 2006-02-28 02:09:34 EST
If you can provide a solution which produce the correct result with less
bandwidth, then please go ahead and do so. Producing an incorrect result in
order to save bandwidth is not acceptable.

The priority should be raised because using FC3 where rhn-applet would do the
right thing is no longer an option. But some bug in bugzilla causes it to think
I'm not the reporter of this bug.
Comment 12 Seth Vidal 2006-02-28 02:19:38 EST
The solution is not to allow the user to download the information. The solution
is for this information to be available to the user via an automated mechanism.

there are solutions we are working on but the one described in this bug report
would just take time away from more functional and less memory/cpu/bandwidth
intensive solutions.
Comment 13 Kasper Dupont 2006-02-28 02:27:29 EST
That's nice. I don't care how it is done, as long as a non-root user can get a
list of available updates which is not based on outdated information. It could
be done with FC1-FC3 is it going to be possible with FC4 or FC5?
Comment 14 Andy Hudson 2006-02-28 03:57:29 EST
re: Comment 10

I understand the bandwidth/CPU constraints, but it seems strange to allow 
normal users to be able to run the command and then kick them out when it 
doesn't work (because they haven't got the correct permissions.

The access rights of normal accounts mean that they should not be able to make 
systemwide changes, something that should only be carried out by the root 
account. Since yum check-update does not make any system-wide changes (at 
least IMHO) why should the command be disallowed. Yes I know normal users 
cannot write to /var/cache/yum/.

So the way I see it there are two options:
1. Totally dis-allow normal users from using the yum check-update command (And 
give an error message stating that only root can use the command) or
2. Come up with some way for yum to store the metadata when the normal user 
runs check-update, and that the root user can access when using yum

Considering the security aspects of the debate, I'd say 1 is the more feasible 
option. Also I'm guessing that at some point in the future pup will get it's 
own update notification applet.
Comment 15 Jeremy Katz 2006-09-18 16:20:05 EDT
You can now check for updates by asking yum-updatesd when it's running
Comment 16 Kasper Dupont 2009-03-29 08:55:18 EDT
I am seeing stale data from yum check-update on a system running with yum-3.2.21-2.fc10.noarch.

yum-updatesd is not running, and I don't know why. It probably wouldn't have been able to download any meta data anyway, since I never told it which http proxy to use on this network.

In this case yum check-update should warn me, that the meta data is stale. (One hour seems like a reasonable threshold).

Note You need to log in before you can comment on or make changes to this bug.