Bug 732799 - perl rpm attempts writing to /usr/local
Summary: perl rpm attempts writing to /usr/local
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 15
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-23 16:43 UTC by Elliott Forney
Modified: 2011-11-25 02:01 UTC (History)
9 users (show)

Fixed In Version: perl-5.12.4-163.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-13 05:36:09 UTC


Attachments (Terms of Use)
Auto-create site directories (3.26 KB, patch)
2011-10-24 13:01 UTC, Petr Pisar
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 717565 None None None Never

Internal Links: 709466

Description Elliott Forney 2011-08-23 16:43:55 UTC
Description of problem:
Last update of perl rpm attempted to write /usr/local/share/perl5  This causes the update to fail with read-only /usr/local (i.e. NFS mounted).

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

perl-5.12.4-160.fc15.x86_64.rpm
perl-libs-5.12.4-160.fc15.x86_64.rpm

How reproducible:
Always.

Steps to Reproduce:
1.  Set /usr/local to read-only
2.  Attempt to install perl rpm
  
Actual results:
rpm install fails.

Expected results:
rpm should install normally.

Additional info:
System rpms should not write to /usr/local

There appears to be a similar problem in RHEL 6, bug 717565

Comment 1 Elliott Forney 2011-08-23 16:44:16 UTC
Output of attempted rpm install:

# rpm -Uvh perl-5.12.4-160.fc15.x86_64.rpm perl-libs-5.12.4-160.fc15.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:perl-libs              ########################################### [ 50%]
error: unpacking of archive failed: cpio: lstat failed - Permission denied
error: perl-libs-4:5.12.4-160.fc15.x86_64: install failed
   2:perl                   ########################################### [100%]
error: unpacking of archive failed on file /usr/local/share/perl5: cpio: chown failed - Read-only file system
error: perl-4:5.12.4-160.fc15.x86_64: install failed
error: perl-libs-4:5.12.4-159.fc15.x86_64: erase skipped
error: perl-4:5.12.4-159.fc15.x86_64: erase skipped

Comment 2 Petr Pisar 2011-08-24 07:10:58 UTC
This is not pure perl problem. E.g. `filesystem' package writes into /usr/local/ too. This is more general problem.

Perl interpreter searches in different locations for Perl modules. One of the location is /usr/local/{lib*,share}/perl5 where local superuser can install his own modules. (Similar to /usr/local/bin delivered by `filesystem' package.)

Current Perl is quiet if the directory does not exists and current Linux caches dentry misses too, so we can disown the directories. But we cannot guarantee this will be true forever. In fact we had some negative responses on Perl performance when searching nonsearchable directories.

Comment 3 Ralf Corsepius 2011-08-24 07:48:15 UTC
(In reply to comment #2)
> This is not pure perl problem. E.g. `filesystem' package writes into
> /usr/local/ too. This is more general problem.

There are 2 views on this issue:
a) The problem is the OP's use-case. 
/usr/local is not supposed to be networked, but to be machine local directory and not supposed to be read-only.

b) The problem is in rpm. 
rpm should not fail if the directories it tries to install already exist.

Comment 4 Elliott Forney 2011-08-29 20:53:10 UTC
In my opinion it makes sense to have a shared /usr/local.  It is also very convenient and fairly common.  Although I do see that the filesystem package writes there as well, so maybe we should mount it somewhere else.

All that the perl package is trying to achieve is to make sure that /usr/local/share/perl5 exists and has the correct permissions, correct?  What if this was moved out of the cpio and a bit of shell script was instead used to create the directory.  Perhaps then the rpm could give a warning if /usr/local is read-only instead of failing outright?

Comment 5 Petr Pisar 2011-10-03 15:24:44 UTC
Directories under /usr/local will be disowned by perl.

Comment 6 Ralf Corsepius 2011-10-03 16:01:09 UTC
(In reply to comment #5)
> Directories under /usr/local will be disowned by perl.

Veto - This would be a mistake.

(In reply to comment #4)
> In my opinion it makes sense to have a shared /usr/local.
Rest assured, it doesn't.

>  It is also very
> convenient and fairly common.
It is only common for folks who are not familiar with the FHS and not familiar with Unix history.

The original purpose of /usr/local was to override /usr in search paths on commercial systems where /usr was considered read only. This also is the reason why GNU packages typically install to /usr/local as default, because they presume usrs who install GNU SW, intend to replace vendor SW components with GNU components, without physically destroying the vendor SW.

If you want to share packages between machines, /srv is what you are looking for.

Comment 7 Elliott Forney 2011-10-03 23:51:12 UTC
You said it yourself, /usr/local is where users can override system packages.  Hence, system packages should not write to /usr/local.

Let's consider some not so hypothetical questions.

First, assume that you have an entire computer lab or rack of machines that are running a commercial non-gnu operating system (of course we would all try and avoid that but it happens).  Now say that you want to install a number of gnu packages on each of these machines to override the system packages.  Do you spend your entire weekend installing the packages in /usr/local on each machine individually?  or do you NFS mount /usr/local and install the packages once?  or do you simply abandon /usr/local and put them somewhere else?

Next, assume that the vendor of your non-gnu operating system begins releasing packages that write to /usr/local.  How would you feel about that?

Now, consider that we are running linux.  What's the difference?

Assume that we have concluded that /usr/local is for stand-alone systems only and that shared/distributed installs should go somewhere else instead.  What happens when this location becomes popular? Won't you also need to put your perl search paths there too?

Comment 8 Elliott Forney 2011-10-03 23:53:51 UTC
Finally, here is a quote from the Filesystem Hierarchy Standard http://www.pathname.com/fhs/pub/fhs-2.3.html about /usr/local:

"It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr"

Note the word "shareable."  Here is a quote about /srv:

"This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed."

I believe the standard speaks for itself.

Comment 9 Petr Pisar 2011-10-24 13:01:26 UTC
Created attachment 529865 [details]
Auto-create site directories

perl-5.14.2-196.fc17 does not own the directories. It just prints notice on installation.

Iain does not like the notice. This patch tries to create and remove the directories if possible. Thus users with read-only /usr/local gets the message.
However the patch is obtrusive (from my point of view) and I'm not sure it works in all cases. Feel free to test it or propose better code implementing this automatism.

I'm not confident to push this patch into repositories. Personally I like current always-notice without touching file system because it's simple and give advice in all cases.

Comment 10 Iain Arnell 2011-10-24 13:28:08 UTC
Iain's a lot happier about the notice now that he'll (hopefully) never see it.

Comment 11 Ralf Corsepius 2011-10-24 13:38:09 UTC
And Ralf's finds Petr's changes to be absurd.

Comment 12 Tom "spot" Callaway 2011-10-24 13:44:18 UTC
It does seem like perl-CPAN should try to create /usr/local/ directories as needed (not in the package, but upon execution of CPAN) instead of this hackery.

Comment 13 Petr Pisar 2011-10-24 14:08:15 UTC
Of course perl-CPAN should do it. Question is what about users installing packages manually? Even without cpan utilities?

I thought some notice at perl-libs installation could be great. However nobody seems to like it. Removing all %post* code from spec file is the easiest solution. Is everybody satisfied with silent perl-libs?

Comment 14 Tom "spot" Callaway 2011-10-24 14:22:42 UTC
I don't think that is a case for concern. I think if users installing from CPAN aren't having problems, and we know that users installing custom RPM perl packages they've made that install into /usr/local will not have problems (RPM will make the necessary directories), then we're only worried about manual unpacking of tarballs or weird relocatable RPM issues (which we already don't support for a number of reasons).

I think it is perfectly acceptable for the perl package to simply not own dirs in /usr/local and not print out anything about it.

Now, if there is an issue where perl is trying to index/search pathing below /usr/local which does not exist and perl is having a problem as a result, that seems like a separate bug that should be addressed in perl itself.

Comment 15 Petr Pisar 2011-10-24 16:18:37 UTC
The message will be removed in perl-5.14.2-198.fc17.

Comment 16 Fedora Update System 2011-11-02 12:26:18 UTC
perl-5.14.2-189.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/perl-5.14.2-189.fc16

Comment 17 Fedora Update System 2011-11-02 17:54:12 UTC
Package perl-5.14.2-189.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-5.14.2-189.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15276
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2011-11-03 21:52:53 UTC
Package perl-5.14.2-190.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-5.14.2-190.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15276
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2011-11-04 15:41:15 UTC
perl-5.12.4-163.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/perl-5.12.4-163.fc15

Comment 20 Petr Pisar 2011-11-04 15:45:47 UTC
F14 not affected.

Comment 21 Elliott Forney 2011-11-10 21:25:06 UTC
Thanks all!  I think this is the appropriate solution.

Comment 22 Fedora Update System 2011-11-13 05:36:09 UTC
perl-5.14.2-190.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2011-11-25 02:01:28 UTC
perl-5.12.4-163.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


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