[root@host ~]# yum clean all Loaded plugins: fastestmirror, protectbase Cleaning up Everything Cleaning up list of fastest mirrors [root@ost ~]# yum search libcli Loaded plugins: fastestmirror, protectbase Determining fastest mirrors * base: centos-distro.cavecreek.net * elrepo: elrepo.imt-systems.com * extras: ftp.ussg.iu.edu * rpmforge: apt.sw.be * updates: mirror.nandomedia.com base | 2.1 kB 00:00 base/primary_db | 2.2 MB 00:19 elrepo | 1.9 kB 00:00 elrepo/primary_db | 469 kB 00:04 extras | 2.1 kB 00:00 ftp://ftp.ussg.iu.edu/linux/centos/5.6/extras/x86_64/repodata/primary.sqlite.bz2: [Errno 14] HTTP Error 500: Server Response Error Trying other mirror. extras/primary_db | 260 kB 00:01 rpmforge | 1.1 kB 00:00 rpmforge/primary | 3.9 MB 00:20 rpmforge: [## ] 471/10722Segmentation fault
Mine is occurring on dag:
# yum clean all Loaded plugins: fastestmirror, priorities Cleaning up Everything Cleaning up list of fastest mirrors # yum check-update Loaded plugins: fastestmirror, priorities Determining fastest mirrors * addons: mirrors.tummy.com * base: mirrors.netdna.com * extras: yum.singlehop.com * rpmforge: apt.sw.be * updates: yum.singlehop.com RE | 2.1 kB 00:00 RE/primary_db | 70 kB 00:00 addons | 951 B 00:00 addons/primary | 202 B 00:00 base | 1.1 kB 00:00 base/primary | 954 kB 00:00 base 2683/2683 dag | 1.1 kB 00:00 dag/primary | 4.0 MB 00:11 dag: [####### ] 891/10953Segmentation fault
Frank M. Ramaekers Jr.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Lars Hecking Sent: Tuesday, July 26, 2011 9:01 AM To: centos@centos.org Subject: [CentOS] yum segfault - rpmforge problem?
[root@host ~]# yum clean all Loaded plugins: fastestmirror, protectbase Cleaning up Everything Cleaning up list of fastest mirrors [root@ost ~]# yum search libcli Loaded plugins: fastestmirror, protectbase Determining fastest mirrors * base: centos-distro.cavecreek.net * elrepo: elrepo.imt-systems.com * extras: ftp.ussg.iu.edu * rpmforge: apt.sw.be * updates: mirror.nandomedia.com base | 2.1 kB 00:00 base/primary_db | 2.2 MB 00:19 elrepo | 1.9 kB 00:00 elrepo/primary_db | 469 kB 00:04 extras | 2.1 kB 00:00 ftp://ftp.ussg.iu.edu/linux/centos/5.6/extras/x86_64/repodata/primary.sq lite.bz2: [Errno 14] HTTP Error 500: Server Response Error Trying other mirror. extras/primary_db | 260 kB 00:01 rpmforge | 1.1 kB 00:00 rpmforge/primary | 3.9 MB 00:20 rpmforge: [## ] 471/10722Segmentation fault
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
_____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at PrivacyAct@ailife.com.
I'm having trouble to get rules in /etc/security/console.perms.d to work properly. I have found no clue reading forums. The same problem appear also in Scientific Linux6 and Fedora13/14. The rule i add works fine on centos 5.
hostname:/etc/security/console.perms.d# ls -l total 4 -rw-r--r-- 1 root root 283 Jul 26 15:48 51-local.perms hostname:/etc/security/console.perms.d# head -2 51-local.perms <usbserial>=/dev/ttyUSB[0-9]* <console> 0660 <usbserial> 0660 root.uucp
When i read docs for RHEL 6.1 i found this Removed references to 50-default.perms, since this file was removed in Red Hat Enterprise Linux 6, per Bugzilla 630524.
I have no access on redhat and cannot read the bugzilla report. COuld be related to my issue.
ANyone who knows what the problem is or have any workarounds for this?
/Thomas
00:01 rpmforge | 1.1 kB 00:00 rpmforge/primary | 3.9 MB 00:20 rpmforge: [## ] 471/10722Segmentation fault
We've had the same problem. It helped to recursively delete all cached files in /var/cache/yum. Just run yum update again and you shoudl be fine.
We've had the same problem. It helped to recursively delete all cached files in /var/cache/yum. Just run yum update again and you shoudl be fine.
This does not help here. I started from an empty /var/cache/yum directory. The problem is related to rpmforge, there is no segfault with --disablerepo=rpmforge.
On 07/26/2011 04:33 PM, Lars Hecking wrote:
We've had the same problem. It helped to recursively delete all cached files in /var/cache/yum. Just run yum update again and you shoudl be fine.
This does not help here. I started from an empty /var/cache/yum directory. The problem is related to rpmforge, there is no segfault with --disablerepo=rpmforge.
this is a problem with the metadata from rpmforge, a couple of guys are working through the issue in #yum on irc.freenode.net, feel free to join them.
- KB
On Tue, 2011-07-26 at 16:40 +0100, Karanbir Singh wrote:
this is a problem with the metadata from rpmforge, a couple of guys are working through the issue in #yum on irc.freenode.net, feel free to join them.
Seems an issue with yum too, seeing that it segfaults over bad data. This has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=725798
And for those reporting it here, please mention OS and package version if you report issues.
Regards, Leonard.
We have the same problem with DAG repositories.
Regards, Mathieu.
Le 26/07/2011 17:59, Leonard den Ottolander a écrit :
On Tue, 2011-07-26 at 16:40 +0100, Karanbir Singh wrote:
this is a problem with the metadata from rpmforge, a couple of guys are working through the issue in #yum on irc.freenode.net, feel free to join them.
Seems an issue with yum too, seeing that it segfaults over bad data. This has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=725798
And for those reporting it here, please mention OS and package version if you report issues.
Regards, Leonard.
On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
Seems an issue with yum too, seeing that it segfaults over bad data. This has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=725798
I dont really see that as a yum issue, the problem is bad metadata in rpmforge.
- KB
On 7/26/2011 12:12 PM, Karanbir Singh wrote:
On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
Seems an issue with yum too, seeing that it segfaults over bad data. This has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=725798
I dont really see that as a yum issue, the problem is bad metadata in rpmforge.
- KB
While the problem is bad metadata, should yum really be left off the hook for segfaulting when it gets bad data? Shouldn't yum catch that error with checks, then exit gracefully with an error code?
(If there are already sanity checks, adding one more to catch a null pointer being passed would be a natural extension of those checks.)
On 07/26/2011 05:19 PM, Thomas Harold wrote:
While the problem is bad metadata, should yum really be left off the hook for segfaulting when it gets bad data? Shouldn't yum catch that error with checks, then exit gracefully with an error code?
sure, but you need to take this upstream to get attention. I just dont see this as an important enough issue to fix within centos here. Expecting valid metadata should be a reasonable assumption.
Maybe we should start signing the metadata as well just as an added step.
- KB
On Tue, 2011-07-26 at 17:22 +0100, Karanbir Singh wrote:
sure, but you need to take this upstream to get attention.
This has happened as I mentioned earlier.
I just dont see this as an important enough issue to fix within centos here.
No such suggestion was made. We all know CentOS behaves like upstream and the fix will probably trickle down soon enough.
Expecting valid metadata should be a reasonable assumption.
No. Programmes that crash on bad input are vectors for exploits. Even if it's unlikely someone would put an untrustworthy repo in his config yum shouldn't segfault on bad data.
Regards, Leonard.
On 07/26/2011 05:34 PM, Leonard den Ottolander wrote:
I just dont see this as an important enough issue to fix within centos here.
No such suggestion was made. We all know CentOS behaves like upstream and the fix will probably trickle down soon enough.
ah you see, we have a bit of room when it comes to yum and package management, if there was a major issue in the way rpm/yum works, we *should* consider local fix's. With due testing and perhaps limited release as the first few rounds.
- KB
On Tue, 2011-07-26 at 18:34 +0200, Leonard den Ottolander wrote:
On Tue, 2011-07-26 at 17:22 +0100, Karanbir Singh wrote:
sure, but you need to take this upstream to get attention.
This has happened as I mentioned earlier.
I just dont see this as an important enough issue to fix within centos here.
No such suggestion was made. We all know CentOS behaves like upstream and the fix will probably trickle down soon enough.
Expecting valid metadata should be a reasonable assumption.
No. Programmes that crash on bad input are vectors for exploits. Even if it's unlikely someone would put an untrustworthy repo in his config yum shouldn't segfault on bad data.
Programmes should ALWAYS ensure the data they will operate on is VALID.
Programmes should INSIST on valid data or REJECT that data with a concise, but sufficiently comprehensive, error message.
Programmes that abort because of bad data are defective programmes and need rectification. No good programmer ever accepts that other people's data will always be valid.
On Tue, 26 Jul 2011, Always Learning wrote:
*snip*
Programmes that abort because of bad data are defective programmes and need rectification. No good programmer ever accepts that other people's data will always be valid.
+1
Kind Regards,
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Jul 26, 2011, at 2:03 PM, Keith Roberts keith@karsites.net wrote:
On Tue, 26 Jul 2011, Always Learning wrote:
*snip*
Programmes that abort because of bad data are defective programmes and need rectification. No good programmer ever accepts that other people's data will always be valid.
+1
I might add that no good programmer should accept ANY data as valid without verification. Theirs, ours, we're all human and make errors.
-Ross
On Thu, 28 Jul 2011, Ross Walker wrote:
To: CentOS mailing list centos@centos.org From: Ross Walker rswwalker@gmail.com Subject: Re: [CentOS] yum segfault - rpmforge problem?
On Jul 26, 2011, at 2:03 PM, Keith Roberts keith@karsites.net wrote:
On Tue, 26 Jul 2011, Always Learning wrote:
*snip*
Programmes that abort because of bad data are defective programmes and need rectification. No good programmer ever accepts that other people's data will always be valid.
+1
I might add that no good programmer should accept ANY data as valid without verification. Theirs, ours, we're all human and make errors.
-Ross
I guess that can be applied to stack overflow attacks as well? ie a decently written program should take such vulnerabilities into account, and make provision to deal with them in a clean way?
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On Tue, 2011-07-26 at 17:12 +0100, Karanbir Singh wrote:
I dont really see that as a yum issue, the problem is bad metadata in rpmforge.
A programme that crashes on bad input is what I'd call broken. Abort yes, segfault no.
Regards, Leonard.
On Tue, Jul 26, 2011 at 05:12:23PM +0100, Karanbir Singh wrote:
On 07/26/2011 04:59 PM, Leonard den Ottolander wrote:
Seems an issue with yum too, seeing that it segfaults over bad data. This has been reported upstream: https://bugzilla.redhat.com/show_bug.cgi?id=725798
I dont really see that as a yum issue, the problem is bad metadata in rpmforge.
A segfault is a bug, even if it's only triggered by bad data :-)
(thought: could bad metadata cause an exploitable segfault?)
On Tue, 26 Jul 2011, Stephen Harris wrote:
I dont really see that as a yum issue, the problem is bad metadata in rpmforge.
A segfault is a bug, even if it's only triggered by bad data :-)
I agree. It should report that the checksum is bad, and skip to the next repo.
(thought: could bad metadata cause an exploitable segfault?)
I hope not! In either case, it is Redhat's issue, not ours, and the bug should be filed with them.
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
-
Always Learning -
Daniel Heitmann -
Frank M. Ramaekers -
Gilbert Sebenste -
Karanbir Singh -
Keith Roberts -
Lars Hecking -
Leonard den Ottolander -
Mathieu Carré -
Ross Walker -
Stephen Harris -
Thomas Harold -
Thomas Johansson