Skip Menu |

This queue is for tickets about the ExtUtils-Install CPAN distribution.

Report information
The Basics
Id: 40976
Status: open
Priority: 0/
Queue: ExtUtils-Install

People
Owner: Nobody in particular
Requestors: grousse [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.52
Fixed in: 2.16



Subject: New files installed without user-write permission
All new files installed through ExtUtils::MakeMaker-generated makefiles are installed without user-writable permission bit set. As a consequence, all attempt to modify them during installation with a non-privilegiated user (typically, package building) fails. PDL installation is a good example: couldn't open /home/guillomovitch/cooker/perl-PDL/BUILDROOT/perl-PDL-2.4.4/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/PDL/Index.pod at Doc/scantree.pl line 44. [guillomovitch@n2 perl-PDL]$ ll /home/guillomovitch/cooker/perl-PDL/BUILDROOT/perl-PDL-2.4.4/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/PDL/Index.pod -r--r--r-- 1 guillomovitch users 10763 2008-11-16 19:23 /home/guillomovitch/cooker/perl-PDL/BUILDROOT/perl-PDL-2.4.4/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/PDL/Index.pod Removing 1.52 version, so as to use perl-5.10 provided 1.44 version, fix the issue.
On Sun Nov 16 13:41:21 2008, GROUSSE wrote:
Show quoted text
> All new files installed through ExtUtils::MakeMaker-generated
> makefiles are installed without user-writable permission bit set.
[...]
Show quoted text
> Removing 1.52 version, so as to use perl-5.10 provided 1.44 version,
> fix the issue.

seems to be fixed with extutils::makemaker 1.54

On Sun Jan 03 04:43:44 2010, JQUELIN wrote: Show quoted text
> On Sun Nov 16 13:41:21 2008, GROUSSE wrote:
> > All new files installed through ExtUtils::MakeMaker-generated > > makefiles are installed without user-writable permission bit set.
> [...]
> > Removing 1.52 version, so as to use perl-5.10 provided 1.44 version, > > fix the issue.
> > seems to be fixed with extutils::makemaker 1.54
The original poster appears to have been satisfied. This ticket should be closable. Thank you very much. Jim Keenan
Le Dim 16 Nov 2008 13:41:21, GROUSSE a écrit : Show quoted text
> All new files installed through ExtUtils::MakeMaker-generated > makefiles > are installed without user-writable permission bit set. As a > consequence, all attempt to modify them during installation with a > non-privilegiated user (typically, package building) fails. PDL > installation is a good example:
I have the same problem, building a package as an unprivileged user, we end up with all files being installed a 444 or 555 (say, for .so), and then, if we want to strip the .so, it fails because strip can't write to the file, because it's not writable. Changing the line (~812) "$mode = 0444 | ( $mode & 0111 ? 0111 : 0 );" to "$mode = 0644 | ( $mode & 0111 ? 0111 : 0 );" Fixes the problem.
Dne Ne 16.lis.2008 13:41:21, GROUSSE napsal(a): Show quoted text
> All new files installed through ExtUtils::MakeMaker-generated > makefiles > are installed without user-writable permission bit set.
ExtUtils::Install 2.14 POD reads: Copies each directory tree of %from_to to its corresponding value preserving timestamps and permissions. Therefore the current behavior is not in line with the documentation. The code currently does: $mode = 0444 | ( $mode & 0111 ? 0111 : 0 ); $mode = $mode | 0222 if $realtarget ne $targetfile; _chmod( $mode, $targetfile, $verbose ); So it effectively changes permissions so that they are the same for an owner, a group, and the others. It also always enables read permissions and write permission at the ($realtarget ne $targetfile) condition. I can image this mangling was done to work around CPAN distributions with wrong permission bit in the sources. But this behavior should be documented. Nevertheless the ($realtarget ne $targetfile) condition seems to be the cause of this bug report and should be resolved in the code.
Dne Čt 05.pro.2019 10:47:07, ppisar napsal(a): Show quoted text
> But this behavior should be documented. > > Nevertheless the ($realtarget ne $targetfile) condition seems to be > the cause of this bug report and should be resolved in the code.
The condition is there probably as a workaround for postponed installation on system reboot needed on some operating systems (Win32). So write permissions is not something that ExtUtils::Install wants to expose. I believe that the behavior of not respecting original permissions was implemented as a measure for a case when a CPAN distribution is created with bogus permissions (e.g. on Win32) and then installed on a POSIX system by a root into a system-wide location. Nobody wants to have these files writable for everyone. I implemented a fix (attached) that basically copies write permissions and then clamp all the permissions by applying umask. This way you can still get unexpected write permissions if the distribution is badly archived but you should not get on the risk if your umask (a think you can control) is sane. Alternatively one could force the owner write permission to deal with bogus distributions. Then I executed tests and was surprised that they fail because they check, that installed files are no writable. That actually means that somebody wanted to disable all the write permissions. Unfortunately GIT history is too short. It would be great if the maintainers spoke what do they think about this issue. Is acceptable to start creating writeable files? Should the write permission always be granted or copy the original file permissions? Is applying umask a good meassure or is it an unacceptably fragile solution?
Dne Čt 05.pro.2019 12:37:47, ppisar napsal(a): Show quoted text
> I implemented a fix (attached) that basically copies write permissions > and then clamp all the permissions by applying umask.
Subject: 0001-Preserve-write-permission-and-apply-umask.patch
From 2f608cd791956604eabf8f7d7d98bf1d753c5774 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar@redhat.com> Date: Thu, 5 Dec 2019 17:21:29 +0100 Subject: [PATCH] Preserve write permission and apply umask MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Documentation read: Copies each directory tree of %from_to to its corresponding value preserving timestamps and permissions. but the actual permissions were not preserved. The behavior was that directories were created with 0755 permissions and files with 0444. If the original file had any executable bit set, all executable bits (0111) were set. Write permissions (0222) were set only if the target file could not been overwritten (probably as a measure to allow later renaming a temporary installation location on operating systems that prevents from overwriting opened files). This behavior usually did the right thing. Especially when installing files by a superuser into a location accessible for everyone (e.g. /usr/local). But if the file is installed by a user for himself, he always lost a permission for writing into that file. That's especially troublesome when some postprocessing is needed. See <https://rt.cpan.org/Ticket/Display.html?id=40976> for an example. This patch documents the behavior, but copies all executable bits. And then clamps all permissions by umask, if umask is supported. CPAN RT#40976 Signed-off-by: Petr Písař <ppisar@redhat.com> --- lib/ExtUtils/Install.pm | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/lib/ExtUtils/Install.pm b/lib/ExtUtils/Install.pm index 047c007..29f7486 100644 --- a/lib/ExtUtils/Install.pm +++ b/lib/ExtUtils/Install.pm @@ -586,7 +586,12 @@ sub _chdir { Copies each directory tree of %from_to to its corresponding value -preserving timestamps and permissions. +preserving timestamps. + +Directories are created with 0755 permissions. Files are created with read +permissions for everyone, executable permissions for everyone if the file has +at least one executable bit set, and write permissions are preserved. Then +umask is applied to the permissions. There are two keys with a special meaning in the hash: "read" and "write". These contain packlist files. After the copying is done, @@ -717,6 +722,7 @@ sub install { #XXX OS-SPECIFIC my $tmpfile = install_rooted_file($pack{"read"}); $packlist->read($tmpfile) if (-f $tmpfile); my $cwd = cwd(); + my $umask = umask(); my @found_files; my %check_dirs; require File::Find; @@ -825,7 +831,8 @@ sub install { #XXX OS-SPECIFIC utime($atime,$mtime + Is_VMS,$targetfile) unless $dry_run>1; - $mode = 0444 | ( $mode & 0111 ? 0111 : 0 ); + $mode = 0444 | ( $mode & 0222 ) | ( $mode & 0111 ? 0111 : 0 ); + $mode &= ~$umask if defined $umask; $mode = $mode | 0222 if $realtarget ne $targetfile; _chmod( $mode, $targetfile, $verbose ); -- 2.21.0
Looks like still it is the issue with ExtUtils::Install. When DSO module is installed it is stipped down write permission which is very annoing because it causes issue on rpm packages builds when rpm post installation cannot separate DSO debuginfo in package post installation. I'vce been tring patch atatched to the ticket but looks like it does not help on DSOs installation :/