[Bug 172336] New: getgrnam() crashes with "Out of memory" if /etc/group contains long lines
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172336
Summary: getgrnam() crashes with "Out of memory" if /etc/group
contains long lines
Product: Fedora Core
Version: fc4
Platform: i386
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621
OS/Version: Linux
Status: NEW
Severity: security
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: jvdias(a)redhat.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list@redhat.com,prockai(a)redhat.com
+++ This bug was initially created as a clone of Bug #163958 +++
>From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720
Firefox/1.0.6
Description of problem:
This bug has been fixed in Debian and in newest Perl. I'm just wondering does
this concern RHEL 3 too, because we are rather close having "too much" users in
one group and I would rather see this bug fixed before that we are going to have
problems.
* Fix test of reenterant function return values which was causing
perl to malloc itself to death if ERANGE was encountered before
ENOENT (such as a long line in /etc/group; closes: #227621).
Version-Release number of selected component (if applicable):
How reproducible:
Didn't try
Additional info:
-- Additional comment from jvdias(a)redhat.com on 2005-11-02 16:23 EST --
This is PERL bug 37056, fixed with patch 25084 in bleadperl (5.9.x):
( http://rt.perl.org/rt3/Ticket/Display.html?id=37056 )
Subject: getgrent fails if a line in /etc/groups gets too long
Date: Fri, 02 Sep 2005 15:53:08 +0200
To: perlbug(a)perl.org
From: Michiel Blotwijk <michiel(a)blotwijk.com>
This is a bug report for perl from michiel(a)altiplano.be,
generated with the help of perlbug 1.35 running under perl v5.8.5.
-----------------------------------------------------------------
[Please enter your report here]
The function getgrent throws an error if a line in /etc/groups gets
too long (> 3000 characters). This error can be reproduced as follows:
1/ Manually add a large number of users to a group in /etc/group. It doesn't
really matter if these are real users or not, as long as the line exceeds
3000 characters.
2/ perl -e 'use User::grent; while (my $gr = getgrent() ) { print
$gr->name."\n"; }'
This will return an "Out of memory!" message.
This thread seems to be related:
http://lists.debian.org/debian-security/2005/06/msg00041.html
Originally reported at Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227621
As said in the Debian bug report:
From: "Steinar H. Gunderson" <sgunderson(a)bigfoot.com>
To: Peter Palúch <peterp(a)frix.fri.utc.sk>
Cc: control(a)bugs.debian.org, 227621(a)bugs.debian.org,
debian-security(a)lists.debian.org
Subject: Re: perl: getgrnam() crashes with "Out of memory" if /etc/group
contains long lines
Date: Fri, 10 Jun 2005 15:03:02 +0200
It's about the same bug in perl as it was in glibc. reentr.pl line 698 reads:
$call = qq[((PL_REENTRANT_RETINT = $call)$test ? $true :
(((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE)) ?
($seenm{$func}{$seenr{$func}})Perl_reentrant_retry("$func"$rv) : 0))];
The problem here is "errno == ERANGE". If, at any time, there's a line longer
than the initial buffer, getgrent() (or any in the same family) will get
ERANGE back (and errno will be set to ERANGE). However, this is never reset.
Thus, when getgrent_r() hits EOF, it returns ENOENT, _but errno is still
ERANGE_. Perl figures the buffer was too small, doubles it and tries again,
but still gets ENOENT, of course (and errno is still ERANGE). This goes on
forever and ever until you run out of memory (which happens quite fast).
The solution is simply to remove "errno == ERANGE" AFAICS; getgrent_r() does
not define what happens to errno, and the return message will always be
ERANGE if the buffer is too small.
I'm a bit tempted to tag this "security"; if a user can (say) change his or
her own GECOS field to make it long enough, Perl programs using getpwent()
will crash, for instance. I can't find any direct way to exploit it (chfn
limits the length of the fields, for instance), but I'm still slightly
concerned over the possibilities of a DoS; Cc-ing debian-security.
/* Steinar */
I agree this bug has security implications .
This problem affects all {get,set}* nss perl wrapper functions, not only
getgrent .
This problem affects all previous releases of PERL in all current Red Hat
releases.
The patch is very straightforward - replace all occurences of
((PL_REENTRANT_RETINT == ERANGE) || (errno == ERANGE))
with
(PL_REENTRANT_RETINT == ERANGE)
in reentr.inc and reentr.pl.
This bug is now being fixed in these perl versions:
Rawhide / FC-5 : perl-5.8.7-0.7.fc5
FC-4 : perl-5.8.6-16
RHEL-4 : perl-5.8.5-17.RHEL4
RHEL-3 : perl-5.8.0-90.2
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 7 months
[Bug 191387] New: RFE: support for perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191387
Summary: RFE: support for perl-Spreadsheet-ParseExcel
Product: Fedora Extras
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-Unicode-Map
AssignedTo: gauret(a)free.fr
ReportedBy: mpeters(a)mac.com
QAContact: extras-qa(a)fedoraproject.org
CC: extras-qa(a)fedoraproject.org,fedora-perl-devel-
list(a)redhat.com
RFE - support for perl-Spreadsheet-ParseExcel
Spreadsheet::ParseExcel is a perl module that requires modification to
Unicode::Map in order to fully function.
At a minimum, the following lines need to be added to Unicode/Map/REGISTRY:
name: CP932Excel
srcURL: $SrcUnicode/VENDORS/MICSFT/WINDOWS/CP932.TXT
src: $DestUnicode/VENDORS/MICSFT/WINDOWS/CP932.TXT
map: (which you copied directry)/CP932Excel.map
# Don't remove this line
It would not be appropriate for perl-Spreadsheet-ParseExcel to modify that file
itself, since it does not own it.
-=-
Additionally, there is the issue of the CP932Excel.map file
perl-Spreadsheet-ParseExcel is a noarch package, but the correct place for the
map file is in an arch dependent directory (ie
i386-linux-thread-multi/Unicode/Map/MS/WIN/ )
There are two options - I can install the file as part of
perl-Spreadsheet-ParseExcel and make the package arch dependent, or the file can
be added to the Unicode::Map package.
I would prefer the latter, but would be willing to do the former.
-=-
The README file describing this can be viewed at
http://search.cpan.org/src/KWITKNR/Spreadsheet-ParseExcel-0.2603/README
The needed map file is at
http://search.cpan.org/src/KWITKNR/Spreadsheet-ParseExcel-0.2603/CP932Exc...
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 8 months
When to use perl(:WITH_...) requires?
by Chris Weyl
Hey all --
Perl provides a number of provides flags, e.g.:
perl(:WITH_ITHREADS)
perl(:WITH_LARGEFILES)
perl(:WITH_PERLIO)
perl(:WITH_THREADS)
Most perl module spec files only deal with perl(:MODULE_COMPAT_5.8.8),
etc. But I see a number of them (arch-specific, typically), do use
these flags, along the lines of:
Requires: %(perl -MConfig -le 'if (defined $Config{useithreads}) {
print "perl(:WITH_ITHREADS)" } else { print "perl(:WITHOUT_ITHREADS)"
}')
etc, etc.
So, when should I use these? Should lines along the one above be
included for all flags in an arch-specific spec file? What's a good
rule of thumb here?
-Chris
--
Chris Weyl
Ex astris, scientia
17 years, 9 months
[Bug 199514] New: suidperl segfaults when different version of perl/suidperl is installed.
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199514
Summary: suidperl segfaults when different version of
perl/suidperl is installed.
Product: Fedora Core
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: imlinux(a)gmail.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
suidperl segfaults when different version of perl/suidperl is installed. This
is kind of a no-duh but I recently installed perl-suidperl without updating
perl. I believe I had version 5.8.8-4 of perl and 5.8.8-5 of perl-suidperl.
When running suidperl as a non-root user I'd get a segfault. An strace listed
some files that could not be found.
After updating perl the error went away. Might be a good idea to have suidperl
require perl-%{version}-%{release}. Incredibly minor but thought I'd mention it.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 9 months
[Bug 190887] New: RFE: move perl-LDAP to Extras
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190887
Summary: RFE: move perl-LDAP to Extras
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-LDAP
AssignedTo: jvdias(a)redhat.com
ReportedBy: steve(a)silug.org
CC: fedora-perl-devel-list(a)redhat.com
As seen in bug #122066, perl-LDAP should really require several modules that are
available in Extras. Since Core packages can't have dependencies on Extras
packages, I think perl-LDAP should be moved to Extras where the correct
dependencies can be added.
It doesn't look like anything in Core requires it in FC5.
# repoquery --whatrequires --alldeps perl-LDAP
smbldap-tools-0:0.9.2-2.fc5.noarch
perl-LDAP-1:0.33-1.2.noarch
amavisd-new-0:2.3.3-5.fc5.noarch
otrs-0:2.0.4-3.fc5.noarch
amavisd-new-0:2.4.0-1.fc5.noarch
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 9 months
[Bug 199287] New: Replace hardcoded .fc6 by %{?dist}
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199287
Summary: Replace hardcoded .fc6 by %{?dist}
Product: Fedora Core
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl-Net-DNS
AssignedTo: jvdias(a)redhat.com
ReportedBy: redhat-bugzilla(a)linuxnetz.de
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Please replace hardcoded .fc6 by %{?dist} in the perl-Net-DNS spec file.
Version-Release number of selected component (if applicable):
perl-Net-DNS-0.58-1
Expected results:
--- perl-Net-DNS.spec 2006-07-17 22:10:44.000000000 +0200
+++ perl-Net-DNS.spec.rsc 2006-07-18 20:10:05.000000000 +0200
@@ -1,6 +1,6 @@
Name: perl-Net-DNS
Version: 0.58
-Release: 1.fc6
+Release: 1%{?dist}
Summary: DNS resolver modules for Perl
License: GPL or Artistic
Group: Development/Libraries
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
17 years, 9 months
