Bug 495636 - Pinning doesn't work as intended
Pinning doesn't work as intended
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: apt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-14 03:35 EDT by Eli Wapniarski
Modified: 2009-04-15 03:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-15 03:02:25 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 Eli Wapniarski 2009-04-14 03:35:17 EDT
I have a problem properly prioritizing the ATrpms repository with apt. There are only several packages that are unique to ATrpms that I want installed on my system. The rest of the packages I want to ignore. I have excluded ATrpms from my preferences file. For every other repository that I access I have set the pin-priority greater than 1000. Which means (as far as I understand) I should see packages for which dependencies are met from repos other than ATrpms. However this is not the case.

I am unable to control ATrpms with apt at all which means that I have been forced to disable the repository and only use yum. And because of a similar problem with yum I must use the includepkgs directive to control what I install from ATrpms. If I do not use the includepkgs statement then Yum wants to install every package from the ATrpms repo whose equivalent is deliberately installed from a different repo with higher prioritization. The ATrpm "override" that I mentioned in yum is absolute when using apt.

This is a security problem. It is a security problem becasue, if ATrpms can manage to override explicit pinning than others can. It would then be possible and indeed likely that a package not intended by a user to be installed or updated is which could either result in a comprised or a broken system.

There is a similar problem with yum. So the bug report for yum will be almost verbatim with this one.

Could you please look into this.
Comment 1 Axel Thimm 2009-04-14 05:11:30 EDT
(In reply to comment #0)
> This is a security problem. It is a security problem becasue, if ATrpms can
> manage to override explicit pinning than others can.

Speaking as an ATrpms representative, I can assure you that ATrpms is not overriding any explicit pinning of yours.

You could argue that the pinning mechanism in apt or its documentation is broken, but that doesn't mean that some repo already is using "security holes" in apt to override your setup.

> It would then be possible
> and indeed likely that a package not intended by a user to be installed or
> updated is which could either result in a comprised or a broken system.

All other points aside, If you assume that some repo you point to has malicious software controlled by a hacking entry, then why should that be limited to the packages you have been excluding? In reality if there were such a scenario all packages from the compromised source would be suspicious, even the ones you do not filter away.

> There is a similar problem with yum. So the bug report for yum will be almost
> verbatim with this one.

yum's and apt's filtering whether its called pinning, priorities, protectbase etc. are quite different.

> I have a problem properly prioritizing [...] Which means (as far as I
> understand) I should see packages for which dependencies are met from repos
> other than ATrpms.
> However this is not the case.

In order for someone to verify any faulty behaviour you should please provide specific examples, best as a minimal bug exposing setup, and the output you get from apt. The typical bug template asks you for steps you took, expected results and actual results.
Comment 2 Eli Wapniarski 2009-04-14 09:29:30 EDT
Axel. I'm not claiming anyone is doing anything malicious. What I am suggesting is that both yum and apt have a problem. In that however the repos are organized, if I prioritize a repo, my explicit instructions should never be overriden. But that's exactly what happens. A user who is not paying attention (and its a likely scenario) since the user generally trusts the software that is being is used can potentially have something installed that is "undesired" due to this unexpected behavior. And, that constitutes a security risk. The behavior is exihibited both by apt and by yum.

My apt's preferences has no reference to the ATrpms repository which means the default priority of 500 It should never override anything with a pin-priority above it. But that's exaclty what happnes. ATrpms overrides everthing else. The output of apt-get -f dist-upgrade is included below. This type of behavior is always reproducable.

-----------
PREFERENCES
-----------
Package: *                         
Pin: release c=fedora-10-x86_64-stable
Pin-Priority: 1004                    

Package: *
Pin: release c=fedora-10-x86_64-testing
Pin-Priority: 1004                     

Package: *
Pin: release c=fedora-10-x86_64-unstable
Pin-Priority: 1004                      

Package: *
Pin: release c=fedora-linux-releases-10-Everything-x86_64-os
Pin-Priority: 1004                                          

Package: *
Pin: release c=fedora-linux-updates-10-x86_64
Pin-Priority: 1004                           

Package: *
Pin: release c=free-fedora-updates-10-x86_64
Pin-Priority: 1002                          

Package: *
Pin: release c=nonfree-fedora-updates-10-x86_64
Pin-Priority: 1002                             

package: rpm
Pin: version 4.6.0-10*
Pin-Priority: 1005    

package: rpm-libs
Pin: version 4.6.0-10*
Pin-Priority: 1005    

package: rpm-build                                                                                                                                           
Pin: version 4.6.0-10*                                                                                                                                       
Pin-Priority: 1005                                                                                                                                           
                                                                                                                                                             
package: rpm-devel                                                                                                                                           
Pin: version 4.6.0-10*                                                                                                                                       
Pin-Priority: 1005                                                                                                                                           
                                                                                                                                                             
package: rpm-python                                                                                                                                          
Pin: version 4.6.0-10*                                                                                                                                       
Pin-Priority: 1005                                                                                                                                           
                                                                                                                                                             
package: wine-capi.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-cms.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-core.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-desktop.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-devel.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-esd.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-jack.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-ldap.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-nas.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-pulseaudio.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-tools.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine-twain.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

package: wine.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005

---------------------
CONTENTS OF LIST FILE
---------------------
repomd http://dl.atrpms.net/f10-x86_64 atrpms/stable

--------------------
apt-get -f dist-upgrade
--------------------

The following packages will be upgraded                                                
   atrpms (71-1 => 73.1-1)                                                             
   faad2-devel (2.6.1-6.fc10 => 2.7-16.fc10)                                           
   lame (3.98.2-2.fc10 => 3.98.2-19.1.fc10)                                            
   libdca (0.0.5-3.fc10 => 0.0.5-4.fc10)                                               
   libdvdcss (1.2.10-1 => 1.2.10-5.fc10)                                               
   libdvdcss-devel (1.2.10-1 => 1.2.10-5.fc10)                                         
   libquicktime-devel (1.0.3-4.fc10 => 1.1.1-25.fc10)                                  
   mjpegtools (1.9.0-0.6.rc3.fc10 => 1.9.0-18.fc10)                                    
   mjpegtools-devel (1.9.0-0.6.rc3.fc10 => 1.9.0-18.fc10)                              
   mplayer-skins (1.8-1 => 1.0-pre3_13.at)                                             
   unrar (3.7.8-3.fc10 => 3.8.4-1.fc10)                                                
   vcdimager (0.7.23-8.fc10 => 0.7.23-9.fc10)
   vcdimager-devel (0.7.23-8.fc10 => 0.7.23-9.fc10)
   x264-devel (0.0.0-0.18.20080905.fc10 => 0.65-9_20090117.2245.fc10)
   yum-plugin-kmdl (0.8-10.fc9 => 0.8-11.fc10)
   zonecheck (2.0.4-3.fc9 => 2.0.4-3.fc10)
The following packages will be REPLACED:
   vcdimager-libs (2.0.2-2.lvn9)
   (by (0.4.9-0.55.20080908.fc10)
   vcdimager) (0.4.9-0.55.20080908.fc10)
The following packages will be REMOVED:
   akode-extras (2.0.2-2.lvn9)
   ffmpeg (0.4.9-0.55.20080908.fc10)
   ffmpeg-devel (0.4.9-0.55.20080908.fc10)
   ffmpeg-libs (0.4.9-0.55.20080908.fc10)
   ffmpeg2theora (0.21-2.fc10)
   gecko-mediaplayer (0.9.5-1.fc10)
   gnome-mplayer (0.9.5-1.fc10)
   gnome-mplayer-common (0.9.5-1.fc10)
   gstreamer-ffmpeg (0.10.5-1.fc10)
   gstreamer-plugins-bad (0.10.9-1.fc10)
   gstreamer-plugins-bad-devel (0.10.9-1.fc10)
   gstreamer-plugins-bad-extras (0.10.9-1.fc10)
   k3b-extras-freeworld (1.0.5-4.fc10)
   kino (1.3.3-1.fc10)
   kino-devel (1.3.3-1.fc10)
   lame-mp3x (3.98.2-2.fc10)
   libquicktime (1.0.3-4.fc10)
   mencoder (1.0-0.104.20090204svn.fc10)
   mjpegtools-gui (1.9.0-0.6.rc3.fc10)
   mjpegtools-libs (1.9.0-0.6.rc3.fc10)
   mozilla-vlc (0.9.8a-1.fc10)
   mplayer (1.0-0.104.20090204svn.fc10)
   mplayer-gui (1.0-0.104.20090204svn.fc10)
   vlc (0.7.23-8.fc10)
   vlc-core (0.9.8a-1.fc10)
   vlc-devel (0.9.8a-1.fc10)
   vlc-nox (0.9.8a-1.fc10)
   x264-gui (0.9.8a-1.fc10)
   x264-gui-devel (0.0.0-0.18.20080905.fc10)
The following NEW packages will be installed:
   libdca0 (0.0.5-4.fc10)
   libdvdcss2 (1.2.10-5.fc10)
   libfaad0 (2.6.1-13.fc10)
   libfaad2 (2.7-16.fc10)
   libmp3lame0 (3.98.2-19.1.fc10)
   libquicktime0 (1.1.1-25.fc10)
   libvcdinfo0 (0.7.23-9.fc10)
   libx264_65 (0.65-9_20090117.2245.fc10)
Comment 3 Axel Thimm 2009-04-14 13:32:18 EDT
(In reply to comment #2)
> What I am suggesting is that both yum and apt have a problem.

Please separate apt and yum, their behaviour/coding is very different. Even if the symptoms may look similar, they need to be addressed in different bug reports.

> In that however the repos are organized, if I prioritize a repo, my explicit
> instructions should never be overriden.

Indeed, but looking at the example you just have a misconfiguration.

> But that's exactly what happens. A user who is not paying attention
> (and its a likely scenario) since the user generally trusts the software that
> is being is used can potentially have something installed that is "undesired"
> due to this unexpected behavior. And, that constitutes a security risk. The
> behavior is exihibited both by apt and by yum.

In this case it looks like user error and this may of course always be a security risk. :)

For yum please open a different bug.

> My apt's preferences has no reference to the ATrpms repository which means the
> default priority of 500 It should never override anything with a pin-priority
> above it. But that's exaclty what happnes. ATrpms overrides everthing else. 

Actually you have never set any preferences for anything else, since wildcards don't work.

> Package: *
> Pin: release c=fedora-linux-updates-10-x86_64
> Pin-Priority: 1004                           

Half a year ago you submitted a feature request (bug #462831), which is still in ASSIGNED state to allow for globing in apt's preferences. So actually you should know beforehand that the config is not valid.

Please confirm and decide for yourself whether this is NOTABUG or a DUPLICATE of bug #462831.
Comment 4 Eli Wapniarski 2009-04-14 15:52:13 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > What I am suggesting is that both yum and apt have a problem.
> 
> Please separate apt and yum, their behaviour/coding is very different. Even if

As indicated, its already been done.

> 
> > In that however the repos are organized, if I prioritize a repo, my explicit
> > instructions should never be overriden.
> 
> Indeed, but looking at the example you just have a misconfiguration.

No sir there is no misconfiguration. ATrpms have not been prioritized at all which means it is equivalent to a preference setting that would read like this

Package: *
Pin: release c=atrpms-stable
Pin-Priority: 500

Quoting from man apt_preferences

"If the target release has not been specified then APT simply assigns priority 100 to all installed package versions and priority 500 to all uninstalled package versions... Note that none of APT's default priorities exceeds 1000"

Which means that none of ATrpms should try to replace or uninstall anything in that I've prioritized above 1000.


> > But that's exactly what happens. A user who is not paying attention
> > (and its a likely scenario) since the user generally trusts the software that
> > is being is used can potentially have something installed that is "undesired"
> > due to this unexpected behavior. And, that constitutes a security risk. The
> > behavior is exihibited both by apt and by yum.
> 
> In this case it looks like user error and this may of course always be a
> security risk. :)

Not noticing is indeed a "user error" but similarly places an unfair burden of responsibility due to unexpected behavior.

> 
> For yum please open a different bug.
> 
> > My apt's preferences has no reference to the ATrpms repository which means the
> > default priority of 500 It should never override anything with a pin-priority
> > above it. But that's exaclty what happnes. ATrpms overrides everthing else. 
> 
> Actually you have never set any preferences for anything else, since wildcards
> don't work.
> 
> > Package: *
> > Pin: release c=fedora-linux-updates-10-x86_64
> > Pin-Priority: 1004                           

Axel please believe me... This works and it works very very well.

 package: kde*
 Pin: release c=fedora-linux-updates-testing-9-x86_64.newkey
 Pin-Priority: 1005

This on the other hand does not. Be that as it may. Having ATrpms trying to replace packages prioritized higher than ATrpms is a no no and a different bug. All together than the feature request to use wildcards for a family of packages.


> Half a year ago you submitted a feature request (bug #462831), which is still
> in ASSIGNED state to allow for globing in apt's preferences. So actually you
> should know beforehand that the config is not valid.

>
> Please confirm and decide for yourself whether this is NOTABUG or a DUPLICATE
> of bug #462831.  

This is neither NOTABUG nor is it a DUPLICATE but 2 completely different issues.

Please, could we stop debating. And bring Panu into the picture. Let him decide whether or not this is a bug. This not a packaging issue but a programming issue.
Comment 5 Eli Wapniarski 2009-04-14 16:33:07 EDT
Actually.. Please wait on this. Maybe a very very very big oops on my part.
Comment 6 Eli Wapniarski 2009-04-14 16:35:38 EDT
Crap crap crap crap... and crap again.... My most sincere and humble apologies. I feel like a complete moron this time..

Completely my oversite.

Please close with my thanks
Comment 7 Axel Thimm 2009-04-15 02:45:29 EDT
(In reply to comment #4)
> Please, could we stop debating. And bring Panu into the picture. Let him decide
> whether or not this is a bug. This not a packaging issue but a programming
> issue.  

Panu had been in the loop since I added him a couple of comments ago.

(In reply to comment #6)
> Crap crap crap crap... and crap again.... My most sincere and humble apologies.
> I feel like a complete moron this time..
> 
> Completely my oversite.

Can you please elaborate for the archive's sake? What was the real problem?

> Please close with my thanks  

I'm not sure who can close it - once you call it a security bug it can't be untagged as such, at least not by me. Try closing it NOTABUG.
Comment 8 Eli Wapniarski 2009-04-15 03:02:25 EDT
First off. Please accept my most humble apologies. I really do feel embarrassed as an ass and an idiot over this.

If I remember correctly. And this was quite some time ago. I had some issues regarding conflicts between rpmfusion - everything (free or nonfree I can't remember). I can't remember the exact circumstances. So the gist of things is that both "everything" repos were disabled under apt. Of course this was supposed to be a temporary situation ;).

I re-enabled the repos and added them to my preferences file along with livna because there is still one package that will not be maintained at rpmfusion but either in livna or freshrpms.

And thats the whole story.

As an aside, in case your curious, the problem that I had with yum was obscurity over a feature in the priorities plugin. It turns out that I needed to add the line:

 check_obsoletes=1

to priorities.conf to deal with this. arrrgh.

Again. Thank you very much. And let this be a lesson to me. Tired and computers don't work very well together. :).

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