Bug 455677 - Autogenerated perl module spec files do not own directories
Summary: Autogenerated perl module spec files do not own directories
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: perl-Digest-SHA1
Version: 4.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Marcela Mašláňová
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 391511
TreeView+ depends on / blocked
 
Reported: 2008-07-16 23:19 UTC by Kevin Graham
Modified: 2018-10-20 03:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-22 13:15:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kevin Graham 2008-07-16 23:19:24 UTC
Description of problem:

This problem exists across most of the packaged perl modules, presumably the
fault of the tool that's responsible for "Specfile autogenerated" (guessing a
variant of cpan2rpm), though I'm not sure what component covers it, so I'm
opening this against an easy example.

These spec files naively generate a %files list from find, ignoring the
directories that will be implicitly created. The problem with this is covered in
bug 83006, and when that bug's fix is integrated these packages will break all
of the time (rather than just when a tighter umask than 022 is used).

$ t=perl-Digest-SHA1; rpm -qi ${t}; rpm -q --dump ${t} | while read p d; do
until [ -z ${p} ]; do echo ${p}; p=${p%/*}; done; done | sort -u | while read p;
do rpm -qf --quiet ${p} || echo UNOWNED: ${p}; done
Name        : perl-Digest-SHA1             Relocations: (not relocatable)
Version     : 2.07                              Vendor: Red Hat, Inc.
Release     : 5                             Build Date: Tue Jun 15 18:48:24 2004
Install Date: Wed Jul 16 14:28:54 2008      Build Host: loma.build.redhat.com
Group       : Development/Libraries         Source RPM:
perl-Digest-SHA1-2.07-5.src.rpm
Size        : 34467                            License: distributable
Signature   : DSA/SHA1, Wed Jan  5 15:30:34 2005, Key ID 219180cddb42a60e
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://search.cpan.org/search?mode=module&query=Digest%3a%3aSHA1
Summary     : Digest-SHA1 Perl module
Description :
The Digest::SHA1 module allows you to use the NIST SHA-1 message
digest algorithm from within Perl programs. The algorithm takes as
input a message of arbitrary length and produces as output a 160-bit
"fingerprint" or "message digest" of the input.

The Digest::SHA1 module provide a procedural interface for simple use,
as well as an object oriented interface that can handle messages of
arbitrary length and which can read files directly.

A binary digest will be 20 bytes long. A hex digest will be 40
characters long. A base64 digest will be 27 characters long.
UNOWNED: /usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/Digest
UNOWNED: /usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/auto/Digest
UNOWNED:
/usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/auto/Digest/SHA1
$


How to reproduce:

# umask
0077
# rpm -i
/systems/jumpstart/Redhat/4WS/x86_64/RedHat/RPMS/perl-Digest-SHA1-2.07-5.x86_64.rpm
# ls -ld /usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/auto/Digest
drwx------  3 root root 4096 Jul 16 16:05
/usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/auto/Digest
#

...obviously the packages will be unusable:

# exit
$ perl -e 'use Digest::SHA1;'
Can't locate Digest/SHA1.pm in @INC (@INC contains:
/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/5.8.5
/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.4/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.3/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.2/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.1/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.0/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.4/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.2/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.1/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
$

Expected results:

The package should own each of the directories that isn't already owned by one
of its dependencies (for most of the Redhat-bundled packages this will just be
perl).

Comment 1 Kevin Graham 2008-07-30 23:56:19 UTC
I'm not familiar with what guidelines exist internally, but perhaps the most
applicable publicly available states clearly:
 
https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership

          In all cases we are guarding against unowned directories being
          present on a system. Unowned directories are affected by the
          umask of the user installing the package and thus can be a
          security risk or lead to packages which won't run. 

Comment 2 Marcela Mašláňová 2008-07-31 10:35:11 UTC
Fix this one will be easy. Now we are using cpanspec for generating new files,
but obviously that doesn't solve problems in all perl's RHEL-4 packages. 

Comment 3 RHEL Program Management 2008-10-31 16:40:51 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 5 Marcela Mašláňová 2010-02-22 13:15:37 UTC
The last planned update of RHEL-4 will be focused on performance and security bugs only. This bug should be solved in next release.


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