FS#17656 - [makepkg] file permission with with fakeroot broken/stripping may fail

Attached to Project: Pacman
Opened by Andreas Radke (AndyRTR) - Wednesday, 30 December 2009, 12:26 GMT
Last edited by Allan McRae (Allan) - Tuesday, 18 May 2010, 01:58 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan de Groot (JGC)
Thomas Bächler (brain0)
Andreas Radke (AndyRTR)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.3.3
Due in Version 3.4.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

strip command fails as regular user and inside fakeroot on files with permission 444 and 555. this makes makepkg failing on certain packages.

Additional info:
* package version(s)
kernel26 2.6.32.2-2
glibc 2.11.1-1
binutils 2.20-3

Steps to reproduce:

find / -perm 444/555
e.g. cp /lib/libproc-3.2.8.so /tmp/
[andyrtr@workstation64 tmp]$ strip --strip-unneeded /tmp/libproc-3.2.8.so
strip: unable to copy file '/tmp/libproc-3.2.8.so'; reason: Permission denied

see also http://mailman.archlinux.org/pipermail/arch-dev-public/2009-December/014751.html
This task depends upon

Closed by  Allan McRae (Allan)
Tuesday, 18 May 2010, 01:58 GMT
Reason for closing:  Implemented
Additional comments about closing:  See final comment
Comment by Pierre Schmitz (Pierre) - Wednesday, 30 December 2009, 12:38 GMT
Isn't this the point of 444 permissions? Why did you mark the files non-writable in the first place? All tools if not run as root should fail on writing non-writable files. (yes, even if the owner could simply chagne this using chmod).

So, there is no bug in strip but your file permissons are wrong. Change them to 755 or 644.
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 December 2009, 13:14 GMT
Search your filesystem in /lib and /usr for 444 and 555 - there must be many packages wrong then.

At least I could build and strip my OpenOffice packages until short before Christmas. Afaik this was right before new toolchain moved to core. So I think it should be toolchain bump or kernel .32 related.
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 December 2009, 14:33 GMT
It is caused by makepkg and fakeroot usage it seems:

without fakeroot some tesfiles look ok when using install -Dm444/555/644/755 command inside a PKGBUILD:
[andyrtr@laptop64 trunk]$ ls -lha pkg/
insgesamt 24K
drwxr-xr-x 2 andyrtr users 232 30. Dez 15:25 .
drwxr-xr-x 5 andyrtr users 456 30. Dez 15:25 ..
-rw-r--r-- 1 andyrtr users 187 30. Dez 15:25 .CHANGELOG
-rw-r--r-- 1 andyrtr users 509 30. Dez 15:25 .PKGINFO
-r--r--r-- 1 andyrtr users 224 30. Dez 15:25 sysctl.conf444
-r-xr-xr-x 1 andyrtr users 224 30. Dez 15:25 sysctl.conf555
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:25 sysctl.conf644
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:25 sysctl.conf755
[andyrtr@laptop64 trunk]$ tar -tvf /home/andyrtr/nfs/arch64/packages/procps-3.2.8-6-x86_64.pkg.tar.gz
-rw-r--r-- andyrtr/users 509 2009-12-30 15:25 .PKGINFO
-rw-r--r-- andyrtr/users 187 2009-12-30 15:25 .CHANGELOG
-r--r--r-- andyrtr/users 224 2009-12-30 15:25 sysctl.conf444
-r-xr-xr-x andyrtr/users 224 2009-12-30 15:25 sysctl.conf555
-rw-r--r-- andyrtr/users 224 2009-12-30 15:25 sysctl.conf644
-rwxr-xr-x andyrtr/users 224 2009-12-30 15:25 sysctl.conf755

with fakeroot used:
[andyrtr@laptop64 trunk]$ ls -lha pkg/
insgesamt 24K
drwxr-xr-x 2 andyrtr users 232 30. Dez 15:23 .
drwxr-xr-x 5 andyrtr users 408 30. Dez 15:23 ..
-rw-r--r-- 1 andyrtr users 187 30. Dez 15:23 .CHANGELOG
-rw-r--r-- 1 andyrtr users 541 30. Dez 15:23 .PKGINFO
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf444
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:23 sysctl.conf555
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf644
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:23 sysctl.conf755
[andyrtr@laptop64 trunk]$ tar -tvf /home/andyrtr/nfs/arch64/packages/procps-3.2.8-5-x86_64.pkg.tar.gz
-rw-r--r-- root/root 541 2009-12-30 15:23 .PKGINFO
-rw-r--r-- root/root 187 2009-12-30 15:23 .CHANGELOG
-r--r--r-- root/root 224 2009-12-30 15:23 sysctl.conf444
-r-xr-xr-x root/root 224 2009-12-30 15:23 sysctl.conf555
-rw-r--r-- root/root 224 2009-12-30 15:23 sysctl.conf644
-rwxr-xr-x root/root 224 2009-12-30 15:23 sysctl.conf755

So is this a fakeroot bug or do we leave the fakeroot environment to late in makepkg?
Comment by Dan McGee (toofishes) - Wednesday, 30 December 2009, 14:44 GMT
I'm confused; what issue are you pointing out in your last comment? I don't see the differences between the two ls outputs outside of the owners of the files.
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 December 2009, 15:14 GMT
With fakeroot the file in pkg dir is 644 instead of 444 -rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf444 - the other was round would make sense why strip is failing.

I wonder where strip is failing over 444/555 that it didn't in the past. Can we also run into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534879 or one of the other open fakeroot bugs?
Comment by Allan McRae (Allan) - Wednesday, 30 December 2009, 21:05 GMT
Can you try updating fakeroot (1.14.4) to see if that helps?

@Andy: is the package having correct permissions in the tarball but not the /pkg dir correct? Or did you copy and paste wrong?
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 14:04 GMT
So... it looks like we have a combination of two "bugs" here.

1) strip does not work on files with 444/555 permissions. This is not a bug in itself. If you do not have write permissions on a file then you should not be able to strip it. I guess an update (coreutils/toolchain/kernel?) fixed that bug. However, the fact makepkg tries to strip files with incompatible permissions is a bug and will cause makepkg to error out in 3.4 (set -e) so must be fixed.

2) fakeroot permission issues. This is the weirdest fscking bug ever! This can be replicated installing a file with 444 or 555 permissions under fakeroot. On exiting fakeroot, these files will end up with 644 or 755 permissions respectively. However, while within fakeroot, they will have the correct permissions. Hence a package will have files with correct permissions (unless -R is used on a PKGBUILD without a package() function).
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 14:27 GMT
Interesting....

allan@arch ~/tmp/fakeroot/pkg
> fakeroot cp -a source.file source.file2

allan@arch ~/tmp/fakeroot/pkg
> ls -l
total 0
-r--r--r-- 1 allan allan 0 Jan 26 00:25 source.file
-rw-r--r-- 1 allan allan 0 Jan 26 00:25 source.file2

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361306 - Thomas submitted a patch for this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521178 - related?
Comment by Thomas Bächler (brain0) - Monday, 25 January 2010, 14:34 GMT
I think my patch was merged in some way (note, this was almost two years ago and I have built packages on ACL-enabled file systems since then without the original bug). You could try to mount a file system without ACL support (build in ext3 or so mounted with the noacl,noxattr option) and see if it still fails.

Also, Andy's comments don't indicate a problem: Once you leave the fakeroot environment, no correct permissions are guaranteed anymore, they are only persistent as long as you are inside the fakeroot.
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 14:43 GMT
I think this is a bug caused by newer coreutils as fakeroot all the way back to 1.9 all suffer.
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 14:48 GMT
> Once you leave the fakeroot environment, no correct permissions are guaranteed anymore, they are only persistent as long as you are inside the fakeroot.

Interesting... I have never heard that before. Well, then this is not a fakeroot bug at all then.

If that is the case, we need a big warning for "makepkg -R" for PKGBUILDs without a package() function as they could result in packages with incorrect permissions.
Comment by Dan McGee (toofishes) - Monday, 25 January 2010, 15:20 GMT
What if we don't allow -R anymore without a package() function?
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 15:27 GMT
Hmm... I had considered that but thought you would be against it! :P

It would break expectations people have about -R, but as long as it is clarified in the man page it should be fine.
Comment by Dan McGee (toofishes) - Monday, 25 January 2010, 15:29 GMT
Haha, I'm just trying to think of a solution that is straightforward and it seems like the best option given the above constraints with fakeroot. Considering repackage right now doesn't completely do what it says it does, I wouldn't be against enforcing this and like you said, documenting it.
Comment by Pierre Schmitz (Pierre) - Monday, 25 January 2010, 15:46 GMT
I would be fine with this. We should also promote using a separate package function which has its advantages especially when using -R.
Comment by Allan McRae (Allan) - Monday, 25 January 2010, 15:54 GMT
Continuing down that path... Do we want to add a deprecation warning for PKGBUILDs without package() functions and make it an error in a few releases time?
Comment by Allan McRae (Allan) - Tuesday, 26 January 2010, 11:18 GMT
Just as a summary for me of the patches needed to makepkg:
1) Only strip files if have write permissions
2) Only use -R with a package() functions
3) Deprecation warning for PKGBUILDs with no package() function (maybe?).
Comment by Allan McRae (Allan) - Tuesday, 18 May 2010, 01:58 GMT
I makepkg is now in about as good a shape as possible with respect to this bug:
http://projects.archlinux.org/pacman.git/commit/?id=a4e3fd18 - only strip files that are writable
http://projects.archlinux.org/pacman.git/commit/?id=6995aed9 - deprecate repackaging without a package function

Loading...